You did the responsible thing. You wired your app to push events to a live feed. A payment lands, your phone buzzes, a little card says who paid and how much. LogSnag made this a habit for a lot of builders, and it is a good habit. Watching real events beat staring at Google Analytics a long time ago.
This post is not about that habit being wrong. It is about the failure mode it cannot see.
The feed can only show what arrived
Friday, 6:12 PM. You rotate your API secrets because a contractor rolled off the project. One of them is the Stripe webhook signing secret. The new value goes everywhere except production.
From that moment, every checkout.session.completed that Stripe sends you fails signature verification. Stripe retries politely, then slows down. Customers keep paying. Plans stop activating.
Now look at your feed. What does this outage look like?
It looks like nothing. No red card, no error event, no buzz. The payments channel just stops moving, and a channel that stops moving looks exactly like a slow evening. You will find out on Monday, from a support email that starts with "I paid twice and still can't log in."
Nothing threw, so nothing paged
Here is the uncomfortable part: every alert you have is wired to presence. An error event arrives, you get paged. A threshold is crossed, you get paged. But the webhook that never fires produces no event. The cron that never starts throws no exception. There is no payload to alert on, because the whole problem is that there is no payload.
Two more scenes from the same family:
- Your
nightly-digestcron moves to a new scheduler during a refactor. The schedule string is subtly wrong. The job never runs again. No error, because nothing executed. You notice when a customer asks why the digests stopped two weeks ago. - A background agent kicks off a run and awaits a tool call that never returns. No exception, no timeout, no event. The queue behind it grows in perfect silence.
In all three cases the system is not erroring. It is simply not happening. From the outside, "fine" and "frozen" are identical.
Silence detection: alert on the absence
logs.so starts from the same wedge you already know. A live feed of server events: payments, signups, failures, whatever your app does. Unlimited events, 7-day history, free, no card. The install is one HTTP call, or one prompt pasted into Cursor, Lovable, Bolt, or v0.
The difference is what sits on top of the feed. Silence detection watches each channel's rhythm and pages you when a channel that should have moved, didn't.
Concretely: your payments channel sees a checkout.session.completed roughly every 15 minutes. One quiet stretch hits 26 minutes and logs.so pages you: payments went quiet. No checkout.session.completed for 26 minutes. Expected one every 15.
That page arrives Friday at 6:40 PM, not Monday morning. The fix is a one-line secret update instead of a weekend of lost activations and refunds.
A LogSnag-style feed answers one question. Silence detection answers the other.
A live feed answers "what happened?" It is genuinely useful, which is why you already have one. Silence detection answers the question feeds structurally cannot: "what should have happened and didn't?"
The first question is where you feel good about your app. The second one is where the money dies quietly.
If your events already flow to a LogSnag-style feed, moving them is not a project. The payload is one JSON object with a channel, an event name, and tags. Your coding agent can re-point it in one pass, and the install docs fit on a single page.
The feed is free: unlimited events, 7-day history, no trial clock. When the quiet starts to matter, Pro is $19/mo for silence detection and full history. Self-serve, cancel anytime.
Your feed looking fine is not the same thing as production being fine. Start free and let something watch for the difference.
Related: Vibe-coded an app? The bug that will not page you.
silence, server-side
Get paged when a channel that should have moved, didn't.
Free: unlimited events, 7-day history, no card. Pro is $19/mo for silence detection.