Silent Failure Detection: Issues for Work That Stops Without an Error

Last verified on Nov 10, 2026.

The failure with nothing to search for

A silent failure is work that did not happen, and nothing said so. The signup confirmation was never sent. The nightly sync ran and moved zero rows. A payment provider stopped calling your webhook endpoint. Every dashboard stays green because no request failed.

Detection has to ask about what is missing. That is a different question from "did an error appear?", and it needs a comparison with what is usual.

Four signals, nothing to set up

The Sazabi agent sets up sensors for your project and maintains them over time, and a sensor can ask about an absence as easily as an error. You set nothing up. Four signals feed this page:

For Empty output, the agent reads your logs to find the jobs and the outputs worth watching, then writes and maintains the sensor. Other signals in the group are not covered today.

Example: a digest job that succeeds with nothing

This is an example, not output from a real project. The digest-job service runs at 07

2026-11-08T07:00:01Z INFO  digest-job started batch=daily-digest
2026-11-08T07:00:03Z INFO  digest-job recipients_loaded count=0
2026-11-08T07:00:03Z INFO  digest-job finished status=success sent=0

Every line is at INFO and the job ends in success. A rule that looks for errors never fires. The question that does fire is closer to "Tell me when the daily digest sends far fewer emails than usual."

An example of the issue:

• Name: Daily digest sent no emails
• Description: digest-job finished with status success but loaded zero recipients, where earlier days load a full list. The recipient query is the likely cause.
• Severity: medium

Where the issue shows up

You get one issue, not a log excerpt. The Sazabi docs describe an issue as arriving already investigated: a description of what happened, the agent's explanation of why, and the evidence. A recurrence folds into an open or ignored issue, so a job that stays empty for a week does not produce seven issues.

Notifications follow your own settings. Issue triggered appears in-app, and email, Slack DM or SMS are opt-in per person. A delivery rule can send medium-and-above issues for one component to a team channel. Because a silent failure is easy to ignore, you might route these to the owning team instead of the on-call rotation.

What it needs from your logs

A sensor can only notice a missing event if the event normally shows up. So the work you care about needs to write a line when it runs: a job start, a send, a webhook received. If it does, the agent can find it. Structured fields such as sent=0 give it something to ask about. See the structured logging glossary entry if your logs are free text.

Webhooks from vendors count as events too, so a delivery stream that stops shows up the same way.

Limits

• Work that never writes any log line, success or failure, gives the sensors nothing to compare.
• Some silent failures are not covered today: a write that was acknowledged but never stored, and the same work processed twice.
• Wording alone, such as a line that says "skipped", does not trigger anything by itself.

Related

A silent failure inside a scheduled job has its own page on background job failures. If the missing thing is a business step, read business flow breakage. The vendor-neutral view of lost writes is in the guide to detecting lost writes. Issues detected are metered; see pricing.