My friend Zac Wagle asked me a deceptively simple question: is the internet healthy right now? Not "is my app down." Not "is AWS having a bad day." Not the entire internet in the literal sense, because no one gets that from a side project with a Lambda bill. The practical version: are the major cloud providers, the DNS layer, network services, and AI APIs we all quietly depend on working the way they are supposed to?
Nobody could answer that at a glance. You would have to open a dozen status pages, squint at a dozen dashboards that each define "degraded" differently, and assemble the picture in your head. That is a terrible way to answer a simple question, so I built something to answer it for me.
Meet Barometer, a weather station for the internet. It is open source, it runs for a few dollars a month, and the story of building it is really a story about mistaking the shiny new thing for the point.
Leaning into the metaphor
Once Zac planted the idea, the weather analogy showed up and refused to leave. A barometer does not predict the future. It reads the pressure right now and lets you infer what is coming. That is exactly the job here. Read the public status of major cloud, network, and AI providers every five minutes, normalize the noise into one number, and answer one question at a glance. Is the internet's pressure holding steady, or is a storm rolling in?
The metaphor did more work than I expected. It gave the project a personality instead of just a dashboard. This is not "Provider Status Aggregator 3000." It is a barometer. You glance at it the way you glance at the sky before deciding whether to grab a jacket.
What I thought I was building it to learn
Here is where I have to be honest with you, because you would catch me if I were not.
AWS announced Lambda MicroVMs on June 22, 2026, a genuinely new serverless primitive. It hands each user or AI session its own Firecracker-isolated environment with a dedicated endpoint, and it can suspend and resume with state intact for up to eight hours. It is built for things like AI coding assistants and interactive sandboxes, where every session needs its own persistent, isolated bubble of compute. I read that announcement, got excited, and told myself Barometer would be my excuse to go learn it.
Then I built the thing, and the honest answer arrived. Barometer does not need any of that. There is no user session to isolate and no state to preserve for eight hours, because the whole job runs for a few seconds and exits. A five-minute cron does not need a bubble. It needs a task that runs, finishes, and gets out of the way.
So Barometer runs on a plain, boring, nodejs24.x Lambda on an EventBridge schedule. And that is when the more interesting realization hit me.
The thing I actually learned
Chasing the new MicroVMs primitive sent me down a Firecracker rabbit hole, and that is where I found the part that actually mattered. My "boring" scheduled Lambda has been running on Firecracker microVMs this entire time. So has every Lambda function I have ever shipped since 2018. It is not a feature you turn on. It is the ground I was already standing on.
AWS did not just ship a new product on June 22. They took a piece of infrastructure that has quietly powered more than 15 trillion invocations a month and exposed it as a new, user-facing primitive. The announcement taught me more about the platform I was already using than about the platform I was chasing.
That is a very "the bottleneck is never the stack" moment, and I did not have to go looking for it. It found me while I was busy trying to use the shiny new thing on a job that never needed it.
The stack was never the point. The fit between the tool and the problem was.
That same lesson shaped the monitor itself. The architecture did not need to be impressive; it needed to be honest. Once I stopped trying to make the infrastructure interesting, the real design question became simpler and harder: what should this system do when the signal is missing, ambiguous, stale, or contradictory?
What one five-minute run actually does
I built Barometer end to end in Claude Code, using my usual spec, plan, execute loop. Write the spec first, agree on a plan, then let tests drive the implementation instead of vibes. The whole thing is open source under MIT in the GitHub repo, Terraform included, so you can see exactly how a small serverless job goes together without over-engineering it.
At a high level, an EventBridge schedule triggers one Node 24 Lambda every five minutes. That single function fetches every provider concurrently, normalizes their very different status formats into one schema, applies the availability and U.S. region rules, and produces a single overall reading.
It writes tiered JSON to a private S3 bucket. CloudFront serves those files over HTTPS behind Origin Access Control, with an ACM certificate and a Route 53 custom domain. The vanilla TypeScript dashboard polls the summary file every 60 seconds.
A small alert state machine fires SNS email only on real transitions, debounced so a blip does not wake you. CloudWatch alarms watch the watcher. There are no servers, no API Gateway, and no database, because none of that machinery would earn its keep for a five-minute cron.
Here is a detail I like. The project currently reads nine public provider status feeds and runs two active DNS probes, one against Cloudflare's 1.1.1.1 and one against Google's 8.8.8.8. A status page is a vendor's self-report. A direct probe measures what is actually happening, so the DNS layer everything else depends on gets its own independent check. A good barometer does not take the sky's word for it.
A barometer that lies is worse than useless
The most dangerous thing a monitoring tool can do is report "all clear" when it cannot actually see. A false outage wastes your afternoon. A false all-clear lets a real one run unopposed. So the whole engine is built around one rule: every failure resolves to "I do not know," never to a confident wrong answer.
That rule shows up everywhere in the code. An adapter that cannot reach a provider's feed does not throw and does not guess. It returns "unknown," and unknown is excluded from the math instead of counted as healthy. A provider with no data in a given window renders as a dash, never a reassuring 100 percent, because a fake 100 percent is exactly the lie I refuse to ship. Planned maintenance is excluded too, so a provider's score is never punished for a window it told us to ignore.
The alerting follows the same discipline. A single bad sample does not page anyone. The state machine waits for two, fires only on a real transition, and holds steady through maintenance and unknowns. And when a status feed goes dark, Barometer does not immediately cry outage. It runs a direct health probe first to confirm the provider is actually down, rather than trusting the absence of a signal.
A monitoring system earns trust by being honest about what it cannot see. That is the line between an instrument and a decoration.
The objection I would raise too
Here is the fair version of the skeptic's case, because I would raise it too. Status aggregators are not new. Sites that watch other sites' status pages already exist, and I did not invent the category. This is also a personal project with one writer and no real load, so a clean result proves less than a system under pressure would.
Both are true. Two responses.
The category was never the point. The point was the discipline of the reading: a measurement that fails to "unknown" instead of lying, and an alert that confirms before it fires. Those choices are where the engineering actually lives, and they matter whether or not the genre is crowded.
And the properties that keep a weekend project honest are the same ones that keep a real system honest, which means they matter more under load, not less. A false all-clear is an annoyance on my dashboard and an incident on yours. The single-writer simplicity, the fail-safe reading, and the debounced alerting are not shortcuts I took because the stakes were low. They are the parts I would keep as the stakes rise.
Try it, break it, tell me what's wrong
Barometer is live if you want to read the internet's pressure right now, and the code is on GitHub if you want to see how it fits together or add a provider I missed. Thanks to Zac for the question that started it, because sometimes the best ideas are just a good question someone asks you over coffee.
And if there is a lesson buried in here, it is the one I keep relearning. The newest primitive is not the answer to every problem. The answer is the boring, correct fit between the tool and the job, and more often than not, the capability you were chasing was already running underneath you the whole time.
Related reading
- The Bottleneck Is Never the Stack. The origin of the idea this whole post keeps circling: what actually constrains delivery is rarely the technology.
- The Subsidy, Itemized. What a month of Claude Code actually costs, and why value lives in verified outcomes rather than tokens.
- Still in the Code. Why I lead engineering at a Fortune 100 company and still ship my own software.
