Vanished Event Alerts: An Issue When an Event That Always Happens Stops

Last verified on Nov 10, 2026.

What it catches

Most failures write an error. The expensive ones write nothing. A checkout that stops reaching the confirmation step logs no exception, and neither does a webhook handler that was unregistered by mistake, or a nightly export that no longer starts. What changed is an absence, and absences do not show up in an error inbox.

Vanished event covers that gap. It fires when a line your system used to write regularly stops appearing, while the rest of your traffic looks normal. That second condition matters. If everything went quiet, the cause is probably upstream of the event. If only one event vanished, something in your code or configuration stopped producing it.

Typical causes:

• A deploy removed or renamed a log call, so the event is still happening but is no longer recorded.
• A feature flag, route or consumer was switched off.
• A dependency changed its behavior and the code path that logs the event is never reached.
• A queue consumer lost its subscription and no longer processes one message type.

Example: confirmations stop at lunchtime

This is an example, not output from a real project. Your applications-api service logs one line for every submitted application:

2026-11-08T13:58:02Z INFO applications-api application_submitted id=app_7710 source=web
2026-11-08T14:01:44Z INFO applications-api application_submitted id=app_7711 source=web
2026-11-08T14:03:09Z INFO applications-api page_view route=/apply/review
2026-11-08T14:06:30Z INFO applications-api page_view route=/apply/review

After 14

• Name: Application submissions stopped in applications-api
• Description: application_submitted has not been logged since 14
  UTC. Review-page views continue at their usual rate, so users are reaching the step and the submit action is not completing.
• Severity: high

The agent also attaches what it looked at: the last occurrence, the neighboring events that are still flowing and anything that changed in the logs around 14

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. A sensor is a standing question about your logs, and Vanished event is one of them.

In plain words, the question is: "Has an event that normally happens stopped, while overall traffic is normal?" Regular rhythms, such as a quiet Sunday morning, are part of an event's normal pattern and do not count as vanishing. You do not write an alert rule or choose a threshold.

When the question comes back yes, Sazabi records a signal and starts an investigation. If the cause is real, the investigation opens an issue. If the event stopped for a harmless reason, it closes without one.

What you see and how you get told

The result is an issue in your Issues inbox with a name, a description, a severity from low to critical, an optional component and an agent analysis with evidence. You can ask the agent follow-up questions in the thread, hand the fix to a coding agent with sazabi issues agent-prompt, or resolve, ignore or mute the issue.

An Issue triggered notification goes to your in-app feed by default. Add Slack DM, email or SMS in your own settings, or route to a shared Slack or Microsoft Teams channel with a delivery rule that matches severity, component or owning team. To see the raw detections, run sazabi signals list --type sensor.

What you need

Logs from the production service that writes the event. Any source works, including OpenTelemetry, AWS and Cloudflare. The event must be something the code logs on its own: Sazabi can only notice the absence of a line it has seen before.

What it does not cover

• An event that has never been logged. There is nothing to vanish.
• Events that are rare by nature, where a gap is normal.
• A whole service going silent, which a separate detection handles.
• Missing work with no log line to anchor on.

For a new line rather than a missing one, see new error detection. For a change in how often a line appears rather than whether it appears, see volume shifts. Issues are metered, so check pricing.