Detection
Detection

Missed Schedule Alerts: An Issue When a Cron Job Skips, Repeats or Runs Long

By Sazabi Team

Last verified on Nov 10, 2026.

What it catches

A scheduled job that fails loudly gets noticed. One that does not run leaves nothing to notice: no error, no log line, only an absence that surfaces days later when someone asks where the report is. This detection covers three shapes of that:

  • Skipped: the nightly export did not start on Sunday because the scheduler restarted at the wrong moment.
  • Repeated: a job ran twice after a deploy, and customers got two emails.
  • Long-running: the job started on time but is still going when the next run is due.

The first is the hardest to see, because the evidence is a missing line.

Example: the nightly export skips Sunday

This is an example, not output from a real project. A warehouse-sync job runs at 03

every night and logs when it starts and ends:

2026-11-06T03:00:01Z INFO warehouse-sync job=nightly_export run=started
2026-11-06T03:21:44Z INFO warehouse-sync job=nightly_export run=finished rows=1204331
2026-11-07T03:00:02Z INFO warehouse-sync job=nightly_export run=started
2026-11-07T03:22:09Z INFO warehouse-sync job=nightly_export run=finished rows=1209870
2026-11-08T03:45:00Z INFO scheduler tick ok next_run=2026-11-09T03:00:00Z

There are no lines for the job on the 8th at all. An example issue:

  • Name: nightly_export did not run on Sunday
  • Description: nightly_export normally starts at 03
    and finishes by about 03
    . By 03
    on Sunday it had not started, and the scheduler logged nothing for it.
  • Severity: high
  • Component: warehouse-sync

The analysis can look at what the scheduler was doing around 03

and whether other jobs at that time were also skipped.

How Sazabi sets it up

Only your logs say which jobs you have and when they run. The Sazabi agent reads them, picks out jobs that repeat on a schedule, and sets up sensors for each. You set nothing up. In plain words the question is: "Tell me when the nightly export has not finished by 03

."

Each job is judged on its own. If you change a schedule, the agent maintains the sensor.

How you are told

A miss records a signal and starts an investigation, and the issue opens when the absence is real. It lands when the job is late, not days later. A shared channel with a delivery rule on the owning team is common for jobs, since the person who owns the export is rarely the person on call. A repeat of the same miss while an issue is open folds into it.

What you need

The job's own runs in your logs. That can be a line in a script, the logs from a durable execution platform such as Inngest, Temporal or Dagster, or scheduler logs from your cloud. AWS is a common source for the latter.

Reading the issue

First decide which of the three shapes you have. A skip usually traces to the scheduler: a restart, a deploy, a clock or time zone change, or a lock that never released. A repeat usually traces to two schedulers, or to a retry that was not safe to repeat. A long run traces to the job itself, growing input or a slow dependency. The issue names the shape, and the thread can compare the run against the previous nights.

What it does not cover

  • Jobs that run and log success while doing nothing useful.
  • Work stuck waiting rather than scheduled. See queue wait growth.
  • Jobs with no log line at all when they run, because a check needs evidence of earlier runs.
  • Re-running a missed job. That is up to you.

For writing checks by hand, with last-success timestamps and expected-run queries, read the cron job monitoring guide. Issues Sazabi detects are metered, so check pricing.

What Sazabi detects today

There are no monitors or alert rules to write: the Sazabi agent automatically sets up sensors for your project and maintains them over time. Sazabi opens an issue when one fires.

  • Missed schedule: A cron job didn't run, ran twice or ran long. Example: Nightly export skipped on Sunday.

Frequently Asked Questions

How does it know a job should have run?

From your logs. The agent reads them, notices the job running on a regular schedule, and writes a check that the job finished when it should have, such as by 03:45 for a 03:00 job.

Does it catch a job that ran but did the wrong thing?

Only if the wrong thing shows in the logs. A job that logs success while writing nothing is outside this check. It covers whether the job ran, ran twice or ran long.

Does it work for jobs on a durable execution platform?

It works for any job whose runs appear in your logs, including ones from Inngest, Temporal, Trigger.dev or Dagster log sources, or a plain cron line written by your own script.

Will a job that has never run in my logs be flagged?

No. A check needs evidence that the job exists. The agent finds jobs from the runs in your logs, so a job that has never appeared there is not something it can watch.

Sources

  1. Issue name, description, severity, component, status, analysis and evidence, recurrence handling (accessed Nov 8, 2026)
  2. Issue triggered notifications and delivery rules by severity, component and owning team (accessed Nov 8, 2026)
  3. sazabi signals list with the sensor type filter (accessed Nov 8, 2026)
Send your cron logs to Sazabi