Empty Job Output Alerts: An Issue When a Job Reports Success and Produces Nothing

Last verified on Nov 10, 2026.

What it catches

Green is not the same as done. A job can exit zero after reading an empty input, filtering everything out or hitting a bug that skips the work. Nobody is paged and the dashboard is clean. The Sazabi agent sets up sensors for your project, and Empty output is one of them, set up for the jobs in your logs. It catches:

• A digest job that completes and sends zero emails.
• An import that reads zero records from a feed that normally has thousands.
• A cleanup or export that reports success while writing an empty file.
• A worker that drains a queue in seconds because its query now returns nothing.
• A report whose row count collapses after a schema change.

Example: the daily digest sends nothing

This is an example, not output from a real project. A digest-job runs at 06

2026-11-08T06:00:01Z INFO  digest-job started
2026-11-08T06:00:03Z INFO  digest-job loaded recipients count=0
2026-11-08T06:00:03Z INFO  digest-job queued emails sent=0
2026-11-08T06:00:03Z INFO  digest-job finished status=success duration_ms=2204

By the job's own report this is a success. A sensor for it could ask: "Tell me when a scheduled job finishes successfully having processed zero items, when it normally processes many." Each job is judged on its own, so only digest-job fires.

An example issue:

• Name: digest-job finished with zero recipients and zero emails sent
• Description: At 06
  UTC the job loaded no recipients and queued nothing, then reported success. Every earlier morning in the logs shows recipient counts in the hundreds. A migration that changed the user table's status column ran at 05
  .
• Severity: high
• Component: digest-job

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. It finds the recurring jobs in your logs and fits each sensor to what the job says about its work and how it reports success. For jobs that log a count, a count far below its usual level is caught. For jobs that log nothing numeric, a line that should not appear, such as "no rows" after a query, can do. A job that is meant to find nothing most days is left alone.

Each job is judged on its own, so a new job picked up later gets its own answer, and one empty run does not mix with the others. The agent writes, backtests and maintains the sensors as jobs are added and renamed.

What you see and how you get told

You get an issue that arrives investigated and cites the run and the earlier ones you can compare it with. You can resolve or ignore the issue yourself from the inbox once a later run looks right.

Notifications follow your settings, and delivery rules can send issues by component to the job's owning team. In the thread, ask what changed between yesterday's run and today's. sazabi issues agent-prompt gives you a prompt for a coding agent, and sazabi signals list --type sensor shows signals.

What you need

Jobs have to write logs that reach Sazabi. If you run them on a durable execution platform, Inngest, Temporal and Trigger.dev are among the integrations. The more a job says about its work, the easier it is to tell empty from done.

What it does not cover

• It does not look at the output itself, such as the content of an email or a file.
• A job that never starts is a different question, discussed in the guide to missed schedules.
• Writes that report success and never reach storage are not covered today.
• It cannot know a job is meant to produce something if it never has.

Related

When two systems disagree, use reconciliation mismatches. If a feed behind the job went quiet, see webhook gaps. Volume falling in your product is business metric drift. Billing details are under pricing.