// alerting
Beaam's job is to be worth trusting at 3am. That is mostly a decision problem, not a data problem — here is exactly how the decision is made.
Almost every alert you have ever muted came from a tool that fired on a single sample. A Lambda times out once under a cold start; CPU touches 95% for one poll during a deploy; a health check misses because a load balancer was mid-rotation. None of those are incidents. All of them page you.
After enough of those, the rational move is to mute the channel — which recreates the blind spot the tool was bought to close. A monitoring tool's real failure mode is not missing an incident. It is being ignored when it finds one.
A signal must fail repeatedly inside a window before Beaam will call a service broken — the 2-of-3 rule. Recovery works the same way in reverse, so a service that is flapping does not generate an alert per flap.
This is the single biggest reason Beaam is quiet. It also means Beaam is deliberately a little slower than a tool that fires instantly: roughly a minute or two of confirmation before you hear anything. That is a trade we make on purpose, and it is the right one for a founder who cannot triage a false alarm during a customer call.
You can see the decisions it did not make: held signals are recorded with their reason, so "why didn't you tell me?" has an answer rather than a shrug.
Per-service tools cannot see seams. Sentry knows your errors, Stripe knows your webhooks, Atlas knows your database — and when replica lag causes Lambda errors that cause webhook failures, all three page you separately about the same event.
Beaam evaluates every connected integration together and groups incidents that fail inside the same window — including cascades that unfold across a few minutes as the evidence confirms. When several services degrade it says so in one message, naming each affected service and which one failed first, so you start at the front of the cascade instead of where it surfaced.
It also learns your stack's own shape. From your history it knows which service usually leads a cascade and by how long — "led api-prod by ~90s in four of the last five incidents." And it reads the control-plane change that came first: a deploy, an autoscale, a config change on the provider you connected. So when a change preceded the failure, the alert points at the likely cause — "began ~12m after an Atlas autoscale on Cluster0" — instead of leaving you to compare timestamps at 3am.
An alert is five fixed fields: what service, what triggered, how long, what it correlates with, and where to look. It fits on a phone screen without scrolling. Not a dashboard link. A sentence.
After an alert fires for a service, a 30-minute cooldown suppresses further alerts for it even if a new incident opens — so a service restarting through a bad deploy cannot become twenty messages.
An alert that was computed but never arrived is indistinguishable from no alert. Every send is recorded with a delivery status; failures retry with exponential backoff up to six attempts; and Resend and Twilio webhooks confirm the message actually landed rather than merely being accepted. A broken incident also fans out to your default channels regardless of routing — belt and braces on the one case that matters most.
Two mechanisms, because this is the promise most tools quietly break.
A daily heartbeat tells you Beaam is alive on a normal day. Per-account silence detection alerts you if your own collectors stop reporting, judged on staleness rather than failure count — a collector that stops being scheduled never records a failure, which is exactly how this hides. An independent watchdog runs on a separate cloud account, sharing no infrastructure with the app, probes Beaam every minute, and alerts Beaam's operator if the service goes quiet — so if Beaam stops, something that is not Beaam notices.
Beaam also watches its own collectors per account. If the connection to your provider stops producing data — a revoked role, a deleted stack, an expired token — that is treated as an incident in its own right, because a tenant whose collection has stalled would otherwise see a reassuring dashboard and hear nothing at all.
Honest trade-offs, since they follow directly from the above. Beaam is slower to fire than a single-sample alerter. It does not offer a hundred configurable rules — the curation is the product. It will not page you for every metric it collects; most are charted for context and stay quiet until you opt in. If you want to tune monitoring, you will find Beaam frustrating, and you probably want a different tool.
Because one bad reading is usually not an incident. Beaam needs repeated evidence in a window before it will call something broken — the 2-of-3 rule. A single failed check that recovers on the next poll is a blip, and waking you for it is how monitoring tools train people to ignore them.
You get one message. Beaam correlates incidents inside the same window across every connected integration — including cascades that unfold over a few minutes — so a database problem that takes out three services reads as one incident naming every affected service and which failed first, not three alarms from three tools.
A monitor that is silent because it is broken is worse than no monitor, so silence has to be provable — three ways. A daily heartbeat proves Beaam is alive on a normal day. Per-account silence detection alerts you if your own collectors stop reporting. And an independent watchdog on a separate cloud account, sharing no infrastructure with the app, probes Beaam every minute and alerts Beaam's operator if the service itself goes quiet.
A daily heartbeat. Quiet should mean everything is fine, and the only way to trust that is to hear from Beaam on a normal day too.
Delivery is a ledger, not a fire-and-forget. Every send is recorded with its status, failures are retried with exponential backoff up to six attempts, and provider webhooks confirm actual delivery rather than mere acceptance.