Automatic Outage Detection: An Investigated Issue When a Service Goes Down

Last verified on Nov 10, 2026.

What counts as an outage here

An outage is a service, a feature or a whole flow failing for most of the people or jobs that use it. The checkout API stops answering. A worker fleet stops taking jobs. A container restarts before it can serve a request.

Most of these leave one of three marks in your logs. A source goes silent. The rate of a normal event collapses or explodes. Or the same process keeps dying and starting again. Sazabi looks for those three marks and opens an issue when it sees one.

The three signals behind it

The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs. Three of them feed this page:

• Service went quiet. It asks whether a source that normally sends logs has stopped.
• Volume shift. It asks whether an event's rate is far above or below its usual rate. A drop of request-completed lines toward zero is the typical outage form of it.
• Crash loops. It asks about restarts, out-of-memory kills and failing health checks.

A quiet Sunday night is part of normal behavior and does not count. Each service is judged on its own, so one service going down does not hide behind steady totals, and the issue names the service.

Other signals in this group are not covered today.

Example: a worker fleet goes silent

This is an example, not output from a real project. A config change goes out at 03

2026-11-08T03:51:58Z INFO  export-worker picked up job id=9a1f queue=exports
2026-11-08T03:51:59Z INFO  export-worker config reloaded source=env hash=77c2
2026-11-08T03:51:59Z WARN  export-worker listening on queue=exports-v2

Nothing follows. The service never logs again, and customers' exports pile up behind it. No error line exists for a text search to find, which is why the question has to be about the silence itself.

The issue could read:

• Name: export-worker stopped logging after a config reload
• Description: The service sent no logs after 03
  UTC. Its last line shows it switched to the exports-v2 queue, which no producer writes to.
• Severity: high

That is the version a person reads on their phone: what happened, a likely reason, and the evidence to check.

How you find out

The result is an issue in the Issues inbox. It carries a name, a description, a severity from low to critical, an optional component and a status, plus the agent's analysis and evidence. If the same outage fires again while the issue is open or ignored, the recurrence folds into it. A resolved issue that recurs opens a new one.

An Issue triggered notification goes to your in-app feed first. Shared destinations such as a Slack channel or PagerDuty receive it only when a delivery rule names them, and rules can match severity, component or owning team. For outages, a common rule sends high and critical issues for the payments component to the payments team's Slack channel.

From the issue you can ask the agent follow-up questions, resolve, ignore or mute it, or hand the fix to a coding agent with sazabi issues agent-prompt.

What you need

Logs from the services you care about, flowing into a production project. An OpenTelemetry exporter, a platform integration such as AWS or a host forwarder all work. The Intake page shows per-source volume, so you can confirm a source is sending before you rely on it.

What it does not cover

• A failure that leaves your logs unchanged. If the load balancer in front of a healthy app drops traffic and the app logs stay normal, the app looks fine.
• Probing from outside your network. Sazabi does not offer synthetic checks, so keep your existing tool for those.
• A service that has never logged to Sazabi, because there is no usual level to compare with.

For the failures that stop short of an outage, see performance degradation. The wider family is on the reliability issues page, and the log-volume behavior behind it is on volume shifts. Issues detected are metered, so check pricing.