Something has to watchthe thing that watches.
A monitoring tool that fails silently is worse than none at all: you stop checking, and the quiet reads as good news. This is the whole shape of Beaam, including the parts that exist only to catch Beaam failing.
System diagram
← scroll the diagram →
Nothing in the lower half shares a company, an account, a database, a deploy pipeline or an alert provider with the upper half. That separation is the only reason the lower half is worth drawing.
The path an alert takes
Beaam reads your providers once a minute with read-only credentials, and only reads: there is no code path that writes to a connected account, so a compromise of Beaam is not a compromise of your production.
A single bad reading is not an incident. Beaam waits for repeated evidence before it will call anything broken, then looks across your stack for a common cause — so a database problem arrives as one message rather than five alarms from the five things that depend on it. What you get is a sentence: what broke, for how long, what it correlates with, and where to look.
Everything the product does is reachable four ways — the web app, the HTTP API, the CLI and an MCP server — because they are all thin adapters over one shared implementation rather than four codebases that drift.
Why the judge lives somewhere else
A watchdog inside the system it watches goes down with it, precisely when you need it. So Beaam's runs on a different company's infrastructure — Fly.io, in Frankfurt — with its own account, its own secrets, its own database and its own way of sending mail. Beaam is on Cloudflare; its database is in AWS us-east-1. The judge shares a failure domain with neither.
The watch runs in both directions. The judge probes Beaam every minute and forms its own opinion of whether collection is fresh, rather than believing what Beaam says about itself — a watchdog that only relays the subject's self-assessment is blinded by any bug in that self-assessment. Beaam, in turn, reads the judge's status every minute and raises the alarm if the judge stops completing checks. Neither can go quiet without the other saying so.
The judge is one machine on purpose. Two would mean two alerts for every incident, or leader election to prevent it — coordination in the component whose entire value is being simpler than what it watches.
And something watches both
A mutual watch has one blind spot: both halves dying at once. It is a much smaller surface than a single platform, but it is not nothing, so a third opinion closes it. The judge pings a third-party cron monitor after every completed run, and that service pages us when the pings stop.
It is hosted by a company with no relationship to Beaam, Cloudflare, Fly or Supabase, and the code that sends the ping refuses to run at all if the URL points at any of them. The scenario a dead-man's switch exists for is "everything else is gone" — one sitting on your own infrastructure is gone too.
What reaches you, and what reaches us
These are separate paths, and it is worth being clear about which is which.
- Your incidents reach you. Something wrong in your stack, on the channels you configured.
- Your silence reaches you. If Beaam stops receiving data from one of your connections, that is an alert in its own right — a collector that quietly stops being scheduled never records a single failure, so silence is judged on staleness, not on error counts.
- A daily heartbeat reaches you. One message a day saying Beaam is alive and watching. It is what makes a quiet week evidence rather than an assumption.
- Platform failures reach us. The judge and the dead-man's switch page Beaam's operator, not customers. Beaam being broken is our problem to fix, not another notification for you to triage.
What this does not buy you
Structure is not a guarantee, and a page like this is easy to write dishonestly. The real limits:
- The judge is a single machine. If Fly's Frankfurt region fails, two other things say so — but for that window Beaam is down to one set of eyes.
- The control-plane database is in one region. A full region loss is downtime, not a failover.
- Alerts are only as good as the channels you set up. One email address is a single point of failure that Beaam cannot fix for you.
- One founder, one time zone. The automation pages instantly; a human reply can take hours.
- No SOC 2, no ISO 27001, and no plan to imply otherwise. If a certification is a hard requirement today, Beaam is not the right fit.
This describes what is deployed today, not a target state. Where something does not exist, it is listed above rather than drawn in the diagram.
Questions
What happens if Beaam itself goes down?
A judge on separate infrastructure — a different company, account, region and alert provider — probes Beaam every minute and pages its operator when it stops. Beaam watches the judge in the same way, so neither can silence the other. You also get a daily heartbeat, so a day with no message from Beaam at all is itself a signal.
Why is the watchdog not part of Beaam?
Because a watchdog inside the system it watches goes down with it, at exactly the moment it is needed. Sharing a database, a deploy pipeline or a cloud account with the thing you are checking makes the check decorative.
What access does Beaam have to my infrastructure?
Read-only, always. There is no code path that writes to a connected provider — no restarting, no scaling, no remediation — so a compromise of Beaam is not a compromise of your production.
Where does my data physically live?
The application runs on Cloudflare's network; the control-plane database is Postgres in AWS us-east-1; raw telemetry is in a managed ClickHouse store and expires after 30 days. The judge runs on Fly.io in Frankfurt, deliberately not in the same region or on the same platform as either.