// no-signup product demo
See the moment Beaamasks for your attention.
A real incident from a real storefront we run and break on purpose. It shows the incident-response experience without credentials, signup, or a live customer system.
14:02 · 1 — something breaks
A webhook delivery fails. Beaam says nothing yet.
drop-checkout · webhook signature check failed · held: 1 reading
The webhook signing secret was rotated and never updated in Drop. The storefront still loads and Stripe still charges. One failed reading is not an incident — a deploy or a network blip looks exactly the same — so Beaam records it as held, with the reason, and waits for the next check.
the next checks · 2 — confirmed
It keeps failing. An incident opens.
drop-checkout · checkout is failing · incident open
Repeated evidence inside the window — failing on check after check, not once — is what turns a held signal into an incident. That wait is deliberate: it is the single biggest reason Beaam is quiet.
same window · 3 — a second symptom
Another signal goes bad. You are not paged twice.
drop-checkout · checkout is failing
drop · fulfilment · orders paid but not delivered · grouped — same stack, same window; alert withheld
Drop pushes its own metrics to Beaam, so the cause shows up a second time, downstream. Beaam groups it into the incident already open, records why they belong together, and withholds the second alert. One cause, one message. This second symptom is illustrative.
14:10 · 4 — the alert
One message, sized for a phone.
drop-checkout — checkout is failing
Stripe webhook signatures failing for 8 min. Buyers are paying and receiving nothing. Start here: Stripe dashboard → webhook endpoint.
What broke, for how long, what it costs, and where to look first. Delivered is the provider confirming it reached you, not Beaam assuming so — every send is written to a ledger and retried if it fails. If this service flaps, Beaam holds further alerts for 30 minutes rather than sending twenty.
you open it · 5 — acknowledge
"I'm on it."
drop-checkout · checkout is failing · open
Acknowledging quiets Beaam about this incident while you work on it. Snoozing is the other answer — not now, ask me later. Start here: Stripe dashboard → webhook endpoint → recent deliveries.
14:31 · 6 — it's over
An all-clear, then quiet.
drop-checkout and 1 other service recovered after 29m
Nothing to do — this is the all-clear. Recorded in your history.
Once the signing secret is updated and the checks pass again — repeatedly, the same way they had to fail — Beaam closes the group and sends one all-clear in the same shape as the alert: what recovered and how long it lasted, which service came back first when it was not the one you were alerted about, and the change the alert cited, if it cited one. It goes only where an alert went out, so a recovery nobody was told about stays silent. Never by SMS.
Was it real? Telling Beaam is how its accuracy gets measured.
Nothing needs your attention · form-01 · all quiet
Our own demonstration store, not a customer. See how the decision works →
What you just read
Six steps, and Beaam spoke twice: once when the incident was certain, once when it was over. The held reading, the second symptom and the flapping in between all happened without a message — that is the product working, not a gap in the demo.
The end state matters as much as the alert. "All quiet" is something Beaam confirms on purpose, every day, because silence you cannot verify is indistinguishable from a monitor that has died.
What had to happen before that message was sent
- Repeated evidence. The signal failed several times in a window, not once. A single bad reading during a deploy is not an incident, and treating it as one is how monitoring gets muted.
- Correlation. Every connected service was evaluated together in that window, so a database problem surfacing as three service failures is named once — every affected service listed, first failure first — rather than paging you three times.
- Cooldown. Having alerted for this service, Beaam will hold further alerts for 30 minutes — a service cycling through a bad deploy cannot become twenty notifications.
- Delivery, recorded. The send is written to a ledger with its status, retried with backoff if it fails, and confirmed by the provider's webhook rather than assumed from a 200 response.
// the same incident, end to end
A real store, broken on purpose.
The alert above is not a mock-up of nothing. It comes from Drop — a working storefront Beaam watches the way it would watch yours. Below is the whole loop: what customers saw, what Beaam sent, and what it took to fix.
demonstration store, not a customer. Built by us, monitored by us, and broken deliberately so this page can show you something true. Form/01 is not for sale and nobody is charged.
01 — the storefront
Form/01, 38 of 100 sold
A limited run at $29. Someone clicks buy, the unit is held, Stripe takes the payment. On a good day the file arrives by email about four seconds later.
Drop on Form/01's launch day. Every studio, every release and every price here is invented; the application serving them is not. 02 — what actually happened at 14:02
Payments taken. Nothing delivered.
The webhook signing secret was rotated and never updated in Drop.
Every surface still looked healthy. The storefront rendered, the payment page loaded, Stripe reported success and charged the card. The only thing that stopped was the part nobody watches — and every purchase since 14:02 took payment and delivered nothing.
What the buyer saw. Order confirmed, payment taken, copy on its way — and nothing was on its way at all. This is the failure class Beaam exists for. There is no error page to see, no 500 in a log, and no customer complaint for another twenty minutes. A status check would have reported everything fine.
03 — 8 minutes later
drop-checkout — checkout is failing
Stripe webhook signatures failing for 8 min. Buyers are paying and receiving nothing. Start here: Stripe dashboard → webhook endpoint.
The alert as it arrives — what broke, what it affected, whether it reached you, and the one screen to open next. Not "an anomaly was detected". The service, the symptom, how long, what it costs, and the one screen to open — the same five fields as the panel at the top of this page, because it is the same format.
04 — the recovery
Secret rotated in, queue drained.
Updating the signing secret fixed deliveries going forward. The purchases already taken were not lost: each one sat in a retry queue that had backed off rather than given up, and the creator resent the ones that had stopped trying. Buyers got their file. Nobody had to reconcile a spreadsheet.
Beaam after the fix, on the demonstration account that watches Drop. Quiet is the state it returns to, and the state it stays in. The recovery matters as much as the alert. Knowing quickly is only useful if the damage is still reversible when you find out.
Drop is open source — read exactly what it does, including how it fails.
What the demo cannot show you
Honest limits: the incident is real and so is the application, but the timings on this page are staged rather than measured, and Drop is ours — a store we built and break deliberately, not a customer. It proves nothing about anyone else's stack, and nothing here should be read as a usage figure or a reference. What it demonstrates is the shape of what arrives: the deliberate absence of a graph, a severity taxonomy, or a link to a dashboard you would have to interpret.
The parts that genuinely need your own stack are the ones worth testing for real: whether the defaults are right for your services, and whether the alert lands on your phone. Both take about five minutes on the free plan, which includes sending a real test alert through your own channel.
Start with one URL. Keep building.
Free includes two integrations, five watched services, and email alerts.
Start free →