Observability Gap Alerts: Issues When Your Telemetry Stops Telling the Truth

Last verified on Nov 10, 2026.

You can only act on what your telemetry shows. A gap is when it stops showing it or shows too much: a service that went silent after a config change, or a log line that now carries a customer's email address. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Two of them watch the quality of the logs themselves.

The two live signals

• Service went quiet. A source stops sending logs. The usual story is that the worker fleet goes silent after a config change. It also feeds outage detection, since a crashed service is quiet too.
• Secrets or personal data in logs. Tokens, keys, emails or ID numbers written into log lines. The related page on data exposure goes deeper on that one.

You write nothing for either. The unusual part of this category is that these sensors audit your logging rather than your product.

Example: a worker fleet that stops reporting

This is an example, not output from a real project. The names are made up. Your invoice-worker fleet logs a heartbeat and a line per job, all day. A config change at 22

2026-11-08T22:09:58Z INFO  invoice-worker job_done id=88121 duration_ms=412
2026-11-08T22:10:01Z INFO  invoice-worker job_done id=88122 duration_ms=389
2026-11-08T22:10:04Z INFO  invoice-worker config_reload logger_target=logs.internal.example:5140

After that, nothing. No error, because errors cannot be logged either. A threshold alert on error count never fires, since the count fell to zero. That silence is what the sensor is for. Its question reads: "Has a source that usually sends logs stopped sending any?"

The issue could be named "invoice-worker stopped sending logs after a config reload", with high severity. The analysis points to the last line before the gap and the config reload next to it. It also says whether other services are still reporting, which separates a broken logger from a platform problem.

How to tell a quiet service from a dead one

The issue cannot know whether invoice-worker is processing invoices in the dark. It can tell you when logs stopped, what changed next to that moment and what else is still reporting. Check the Intake page, which shows per-source volume and a source that dropped to zero. In the issue thread you can ask the agent how much that source usually sends.

How you get told

The firing starts an investigation and an issue opens when the problem is real. A planned decommission that closes quietly does not page anyone. Send the Issue triggered notification to the channel your on-call reads, using severity and component rules, and keep the leak issues in a separate security channel. Repeats fold into the open issue; resolving it and seeing another silence opens a new one.

What you need

Logs flowing from the sources you care about, through any supported integration. A source that has never sent anything cannot go quiet, so a new service needs to arrive first.

What it does not cover

• A route or job that never had telemetry. Blind spots are not covered today.
• Log lines Sazabi cannot read. Unreadable formats are not covered.
• Clock skew. Timestamps drifting between hosts are not covered. The clock skew guide shows a by-hand check.
• Quality of the lines themselves, beyond secrets and personal data.

To see how teams think about the signal, read the glossary on telemetry and log forwarding. The pricing page describes how detected issues are metered.