I'm two weeks into a sabbatical from my role as Engineering Manager at MacPaw. The plan was vague on purpose — no fixed itinerary, no "productive sabbatical" checklist. Just time to think, and occasionally, time to build things nobody asked for.
This is the story of one of those things: InternetVitals — a real-time health dashboard for the internet's backbone infrastructure, designed to look and feel like a hospital patient monitor.
The trigger
I think most of us have lived through the same moment: some piece of core infrastructure — AWS us-east-1, Cloudflare, whoever it is this time — goes down, and suddenly half the internet starts behaving like a 300,000-km taxi with a failing engine. Everything technically still runs. Nothing runs well.
One evening, it was Anthropic's Claude that went down. Mildly inconvenient, mostly amusing. And somewhere in that mild inconvenience, an idea showed up: what if you treated the internet like a patient in an ICU? Each backbone service is an organ. Some are more vital than others. And instead of a wall of green/yellow/red status badges, what if the whole thing read like vital signs — pulse, temperature, blood pressure, oxygen saturation?
That's InternetVitals: 41 backbone services — Cloudflare, AWS, Azure, GCP, GitHub, Stripe, major DNS providers, and others — aggregated into a single weighted Health Score, plus four derived "vitals" that map the same data onto a medical metaphor.
This is not a startup
Worth saying clearly: there's no business model here. StatusGator, Downdetector, and a handful of others already do "is the internet down" well, and they have actual distribution. I'm not trying to compete with them. This is a fun project — built because the idea made me laugh, and because I wanted to see how far the joke could go if I actually built it properly.
It went pretty far. There's a "Console" theme now — black background, green monospace text, ASCII progress bars, and a live tail -f /var/log/vitals.log feed of real incidents in syslog format. Mostly an easter egg for the terminal-loving crowd, but it ended up being my favorite part of the whole thing.
What it's actually measuring
Each service gets a weight based on its estimated share of global internet traffic and how much would break if it went down. Cloudflare's CDN layer, for instance, carries a heavier weight than a smaller SaaS status page — losing Cloudflare has a very different blast radius than losing, say, Okta.
The four vitals are all derived from the same underlying check data, just expressed differently:
- Pulse (BPM) — rises with the number of active incidents
- Temperature (°C) — rises as overall health score drops, like a fever
- Blood Pressure — systolic from CDN-layer health, diastolic from DNS-layer health
- SpO2 — redundancy saturation across core infrastructure
None of this is scientifically rigorous. It's a metaphor with a formula behind it, not a research paper. But it makes the dashboard readable in a way a plain list of 41 status badges never would be.
The stack — all Cloudflare, no servers
The whole thing runs entirely on Cloudflare's own infrastructure, which felt fitting given the subject matter:
- Workers (TypeScript, Hono.js) — the runtime for everything
- Cron Triggers — fire every 5 minutes, checking all 41 services in parallel batches
- D1 (SQLite) — stores check history and calculated vitals over time
- KV — caches the current state so the frontend gets instant reads instead of hitting D1 on every request
- Pages — serves the static frontend, vanilla JS, no framework
Most large services use the statuspage.io JSON API, which makes checking them trivial — one unified format. The exceptions (AWS, Azure, GCP, Apple) don't expose a clean public API, so those needed custom parsers: scraping incident HTML, parsing an RSS feed, unwrapping a JSONP response. Unglamorous, but it works.
How it actually got built
Here's the part I find most interesting, more than the product itself: this took about 8 hours, across two evenings, and I barely touched the code directly.
- Concept, in chat. I talked through the idea with Claude — the patient metaphor, the domain name, which services mattered and roughly how to weight them. The goal at this stage was speed, not precision.
- PRD. From that conversation, we built a proper product requirements document — file structure, database schema, API contract, the
wrangler.tomlconfig — everything Claude Code would need to implement the thing without me having to clarify every detail mid-build. - Design. Claude Design took a few iterations — four, roughly — before it landed on the "ICU monitor" look I had in my head. My taste is apparently more specific than I give it credit for.
- Implementation. With the design and PRD in hand, Claude Code did the bulk of the actual build — checkers, cron logic, the frontend. My role narrowed down to review, small adjustments, and deployment.
Why build this on a sabbatical
I expect some people will read this and think: isn't the point of a sabbatical to step away from the thing you do for a living? Fair point. But for me, this kind of building is a different category of work than my day job. No deadlines, no team waiting on a decision, no roadmap — just an idea, an evening, and the ability to go from a half-formed joke to a live product before bed. That's restorative in its own way, even if it looks exactly like work from the outside.
The actual takeaway
The dashboard isn't really the point. The build time is. Eight hours, two evenings, zero lines of code I wrote from scratch. That gap — between "I have an idea" and "it's live" — has compressed dramatically, and I don't think most people have internalized just how much.
If you've got a slightly ridiculous idea you've been sitting on because it felt like too much effort for a side project: it probably isn't anymore.
You can check the internet's current vital signs at internetvitals.com.