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