// proof, not promises
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.
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.
| 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 in a separate cloud account. Querying it with the application's credentials fails with "this Worker does not exist on your account" — separation demonstrated rather than asserted, and the account is now pinned in config so a mis-targeted deploy fails instead of silently co-locating them. |
| 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. |
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.
Stated plainly, because a proof page that only lists wins is marketing.
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.