// proof, not promises
What Beaam candemonstrate today.
Early-stage products usually pad this page with stock photos and fabricated logos. This one lists what has actually been exercised, and says plainly what has not.
Why this page exists
Beaam asks you to trust it with the job of telling you your product is broken. That is a large claim from a young tool, and the usual way of answering it — testimonials, customer logos, a counter of "monitored services" — would be invented at this stage. So instead: verifiable statements, and an explicit list of what is still unproven.
If something on this page turns out to be wrong, that is a bug worth reporting to support@beaam.app.
Verified in production
| Claim | How it was verified |
|---|---|
| Beaam watches its own stack | The founder's production Cloudflare, Supabase, Sentry and MongoDB Atlas accounts are connected and collecting every minute — including the Cloudflare account the product itself runs on, so an outage of the platform hosting Beaam is something Beaam would see. Verified 20 August 2026. AWS was part of this list until it was withdrawn on 14 August; it is no longer connectable and no longer collecting. |
| Detection actually runs, and holds back | The suppression ledger records signals that were evaluated and deliberately not alerted on — for example a Supabase API reachability failure held because it had not yet met the 2-of-3 confirmation. Quiet is a decision, and the decisions are recorded. |
| The watchdog is genuinely independent | It runs on Fly.io in Frankfurt, with its own account, secrets, database and mail provider — a different company from the one hosting the application (Cloudflare) and from the one hosting its database (AWS us-east-1), so there is no shared failure domain left to argue about. Its status endpoint answered ok: true having just judged 34 collectors for itself rather than taking the application's word for them. Until 26 August 2026 this was a Cloudflare Worker in a separate Cloudflare account, pinned by account id so a mis-targeted deploy failed rather than silently co-locating the two; that Worker has since been retired and deleted. The application and the judge now watch each other, and a third-party dead-man's switch watches both — drawn in full on the architecture page. Verified 31 August 2026. |
| Account deletion really deletes | A reproducible smoke test proves six properties on a disposable production account: password reauthentication, exact confirmation phrase, organization and waitlist removal, auth identity gone, login and pre-existing sessions rejected afterwards, and the telemetry expiry window still configured. |
| The alert path works end to end | Signup, connection, first scheduled signal, real delivered test alert, activation, public status publish/rotate/revoke, password recovery and full deletion pass against production, then clean up after themselves. |
| Silence detection caught a real outage | On 16 August 2026 a hung collector cancelled the cron invocation that carries the heartbeat, leaving 3 of 18 integrations collecting while every board stayed green — the failure this product exists to catch, happening to the product itself. Per-account silence detection found it and paged, and the alerts were correct. It is judged on staleness rather than consecutive failures precisely because a collector that stops being scheduled never records a failure. Verified 16 August 2026. |
| Failure and recovery were exercised | Application unreachable, marketing unreachable, stale collection, primary-delivery failure with fallback, recovery notices and maintenance muting were all triggered deliberately before launch. |
Design decisions you can check
Activation is defined so it cannot be gamed: a watched service alone does not count. It requires a service reporting, an enabled default channel, and a successfully delivered test alert. A metric that counts people who may never receive an alert would flatter the product and mislead us.
Alert delivery is a ledger rather than a fire-and-forget log — every send records its status, failures retry with backoff, and provider webhooks confirm actual delivery rather than mere acceptance. An alert that was computed but never arrived is the same as no alert, so it is tracked as such.
Not proven yet
Stated plainly, because a proof page that only lists wins is marketing.
- No customer evidence. No testimonials, case studies or logos, because there are no customers to quote yet. They will appear when they are real and permissioned.
- No long-run false-positive rate. The target is under 5%, with false negatives under 1% — the number that actually matters. Neither has a meaningful sample yet.
- No independent uptime record. Third-party multi-region measurement is in progress and is a launch gate; until it is complete, no uptime figure is claimed.
- No certification. No SOC 2, no ISO 27001.
Check it yourself
The most useful proof is your own. The free plan takes about five minutes to a first watched service and includes a test alert, so you can verify the delivery path on your own phone before trusting it with anything.