PulseDeck

for the curious (and hiring managers)

How PulseDeck works

Five stages, no servers, no database, no bill. The whole thing is visible in the repo — including the probe history itself.

01

Probe

scripts/probe.mjs

Node script (zero dependencies) hits each service with a 10s timeout, recording reachability, latency and HTTP status.

02

Schedule

.github/workflows/probe.yml

GitHub Actions is scheduled to run the prober every 30 minutes (cron */30). GitHub's scheduler is best-effort, so runs actually land every few hours — the dashboard measures the real cadence from probe timestamps and displays that instead of the configured one. Concurrency is locked so two runs never overlap and corrupt state.

03

Store

data branch → state.json

Results land in git itself: rolling samples, daily aggregates and incidents on an orphan data branch. Git is the database — every datapoint is versioned and auditable.

04

Alert

scripts/sync-issues.mjs

An up→down transition opens a GitHub issue; recovery closes it. The full alert → resolve loop, no pager service needed.

05

Serve

app/ + raw.githubusercontent

The Next.js site ships with a bundled snapshot, then swaps in live state from the data branch at runtime — fresh data with zero rebuilds per probe.

Design decisions

Why store monitoring data in git?

It keeps the whole system on free tiers with zero moving parts: no database to host, back up or pay for. Every state change is a commit — the monitoring history is automatically auditable, diffable and restorable.

Why a separate data branch instead of redeploying?

Probing around the clock would mean dozens of deploys a day. Fetching state.json at runtime from the data branch keeps the dashboard live while the site itself deploys only when code changes. Hot data plane, cold deploy plane.

Why GitHub Issues for incidents?

It's the alerting primitive that's already there: timestamped, assignable, commentable, and closable by automation. It mirrors how real on-call rotations track incidents without adding PagerDuty-style cost.

Why not probe every minute?

A deliberate cost/precision trade-off. These are brochure sites, not payment gateways — a few checks a day catches real outages while staying far inside free-tier limits for Actions minutes and git history size. And instead of claiming a cadence, the dashboard measures the real one from probe timestamps: GitHub's scheduler is best-effort, so honest reporting beats a configured number.

What this demonstrates

Scheduled automation

cron-driven GitHub Actions with concurrency guards

Observability

reachability + latency + status codes, p95 aggregates, 90-day history

Incident management

automatic detection, issue filing, auto-resolution, public log

GitOps thinking

git as the source of truth for both code and operational data

CI/CD

lint + typecheck + build on every push; Vercel deploys on merge

Cost-aware engineering

entire pipeline runs on free tiers by design, not accident