Silent Service Alerts: An Issue When a Service Stops Sending Logs

Last verified on Nov 10, 2026.

Silence is not green

Most alerting waits for something to arrive: an error, a slow request, a failed check. A service that stops writing logs sends nothing at all. The process is dead, the deploy dropped its logging config, the agent shipping logs lost its credentials, or traffic stopped reaching it. The dashboard shows a flat line, and a flat line looks calm.

Service went quiet is the Sazabi detection for that. The Sazabi agent sets up sensors for your project and maintains them over time, and a service that goes quiet is a problem every system can have. You set nothing up. You do not list your services or set a silence timeout.

Example: a worker fleet after a config change

This is an example, not output from a real project. A fleet called export-workers normally logs a steady stream of lines as it picks up jobs. A config change at 11

2026-11-08T11:19:42Z INFO export-workers picked up job id=88213 type=csv
2026-11-08T11:19:58Z INFO export-workers job id=88213 finished rows=1450
2026-11-08T11:20:03Z INFO export-workers loaded config version=412

Then nothing. No error is written, because the thing that failed is the writing. Customers wait on exports that never arrive. The sensor asks whether this source is still sending logs, and the answer turns to no. Sazabi opens an issue. An example of what it could say:

• Name: export-workers stopped sending logs at 11
  UTC
• Description: The last line from export-workers was a config load. No logs have arrived since, and nothing else changed in that source's traffic. Either the workers stopped or they can no longer log.
• Severity: high

The evidence is the final lines before the gap, which in this example point at the config load. That narrows the search to the change that came right before the silence.

Two causes, one issue

A quiet source has two very different explanations, and the issue is where the agent gives its reading of which one you have:

• The service stopped. It crashed, was scaled to zero or lost its traffic. This is an outage.
• The logs stopped. The service may be fine, but its pipeline broke, and every other detection is now blind for it.

Both matter. The second is the quieter hazard, since a service that cannot be seen cannot be checked by any other sensor, which is why a quiet source is worth an issue of its own.

Why it does not fire constantly

A service that is always quiet at 3 a.m. should not page anyone at 3 a.m. Regular daily and weekly rhythms are part of a source's normal pattern, so only silence far outside that pattern becomes an issue.

Each source and job is judged on its own, so a single silent worker does not hide behind busy neighbors.

What you see and how you get told

The issue lands in your inbox with name, description, severity and the agent analysis. It triggers an Issue triggered notification: in-app, email, Slack DM or SMS for you, or a shared Slack or Microsoft Teams channel when a delivery rule matches the severity, component or owning team. You can ask the agent follow-up questions in the issue thread, resolve or mute it from the dashboard, Slack, Teams or the CLI, and hand the fix to a coding agent with sazabi issues agent-prompt.

What it needs

Sazabi has to have heard from the source before it can notice the silence. Connect a platform such as AWS, an OpenTelemetry pipeline or any source from the integrations list.

What it does not cover

• A source Sazabi never received logs from. Nothing can go quiet that never spoke.
• Why a service stopped. The agent gives its best reading of the evidence, but it only sees what reached your logs.
• A service that still logs while doing no useful work. A noisy, broken service is a different question, as is a drop in one kind of event, which the vanished events page describes.

Issues Sazabi detects are metered, so see pricing.