Apify Missed Schedule Monitor

Find the Apify schedules that should have started a run and did not, without adding heartbeat code to every Actor or Task.

When a scheduled scraper goes quiet, the usual question is: did it fail, did it run late, did Apify skip it because the previous run was still going, or did the schedule never fire at all? This Actor reads your schedules and run history through the Apify API and answers that for every expected run in the window, one row per schedule.

It is an independent Actor by automa-flow, not an official Apify feature. It only reads your account.

Quick start

1. In Apify Console, open Settings > API & Integrations and create a token you can revoke. The Actor only reads schedules, schedule logs and run history. A scoped token works when it can read your schedules (with their logs) and your Actor runs; a token that cannot read them fails the run as AUTH_SCOPE_INSUFFICIENT and the message names the read that was refused.
2. Paste the token into Apify account token. Leave Schedule IDs empty to check every schedule the token can see, or list the IDs you care about.
3. Run it. You get one row per schedule. Act on MISSING_INVOCATION and RUN_FAILED. SKIPPED_OVERLAP means the previous run was still busy, which is usually expected.

Want to see the output first? Leave the token empty. The run returns a labeled sample (record_type: DEMO_SCHEDULE_CHECK, is_demo: true) instead of checking an account.

What each status means

Status	Meaning
OK	A scheduler run matched the expected time and started inside the grace period.
RUNNING	The matching run has not finished yet. The next check updates it.
WAITING_GRACE	The slot is due, and the grace period is still open.
LATE_START	The matching run started after the grace period.
SKIPPED_OVERLAP	The schedule is exclusive and its previous run was still active, so Apify skipped this start.
RUN_FAILED	The matching run ended as FAILED, TIMED-OUT or ABORTED.
MISSING_INVOCATION	The grace period passed and no run from this schedule exists for the slot.
DISABLED	The schedule is disabled, so nothing was expected.
UNVERIFIABLE_*	The data cannot prove a miss (daylight-saving edge, config edit, short history, duplicate actions, a token that cannot read the schedule log), so the slot is not called missing.
SOURCE_CONTRACT_AMBIGUOUS	Run metadata or the schedule log disagree, so the slot is not called missing.
NOT_FOUND	A schedule ID you listed does not exist.
SOURCE_FAILED	That schedule could not be read. It is not treated as healthy or missing.
OMITTED	Not checked in this run because of maxSchedules or your charge limit. It is checked next time.

A slot is matched by the run's own scheduler metadata (meta.scheduleId, meta.scheduledAt) and the Actor or Task it targets, never by start time alone. A miss or an overlap skip is confirmed by the schedule's own log, where Apify records that it skipped the start or could not start it. If a miss is followed by a late run within six hours, the next check turns it into LATE_START.

Example row

Illustrative values, shortened. Every row also carries the schedule's cron expression, timezone, check window, matched run IDs and a fingerprint.

{
  "record_type": "SCHEDULE_CHECK",
  "schedule_id": "schedule_123",
  "schedule_name": "daily-products",
  "status": "SKIPPED_OVERLAP",
  "severity": "WARNING",
  "expected_invocations": 3,
  "matched_runs": 2,
  "new_incidents": 1,
  "incidents": [
    {
      "status": "SKIPPED_OVERLAP",
      "expected_at": "2026-10-01T19:30:00Z",
      "is_new": true,
      "explanation": "The previous scheduled run was still active when this exclusive occurrence was due."
    }
  ]
}

new_incidents counts problems this check found for the first time, so an alert can fire once instead of on every run. RUN_SUMMARY in the run's key-value store has the totals.

Run it on a schedule

Save a Task with your token and the schedules to watch, then schedule that Task every 15, 30 or 60 minutes. Each schedule keeps its own checkpoint, so a check continues where the last one stopped (up to 24 hours back). Use a different stateNamespace for each Task that should keep its own checkpoint.

For alerts, add a webhook or an integration on the Task (for example on run succeeded) and filter the dataset for rows where new_incidents is above 0. The Actor does not send email, Slack or Telegram messages itself.

A saved Task with an empty token fails as AUTH_MISSING instead of returning sample rows, so a monitoring Task never goes quiet on demo data.

Related automa-flow tools

• Workflows outside Apify: Workflow Heartbeat Monitor watches n8n, Make and cron jobs through a heartbeat at their last successful step, including runs that finish with zero useful output.

Each Actor runs and charges separately. This Actor does not call them.

Pricing

Pay per event:

• Actor start: $0.0005 per run.
• Schedule checked (schedule_checked): $0.001 for each schedule whose check finalized an expected run that no earlier check reported, whether that run was on time, late, failed, skipped or missing.

Free: disabled schedules, schedules with nothing due, slots a later check looks at again, a run that is still in progress (it is charged once, when it finishes), NOT_FOUND, unreadable schedules, the demo and retries.

For example, one schedule that runs every 30 minutes, checked every 15 minutes, costs about $0.10 a day: 96 starts and 48 checked slots. A run never charges more than the maximum cost per run you set (maxTotalChargeUsd in the API). When that limit is reached, the remaining schedules are OMITTED and checked on the next run.

Token and security

The token is a secret input. It is used only as Bearer authentication to https://api.apify.com, and it is never printed or written to the dataset or key-value store. The Actor never creates, edits or deletes schedules, and never restarts runs. It runs with limited permissions of its own.

A rejected token fails the run as AUTH_INVALID. A token that cannot read schedules or runs fails as AUTH_SCOPE_INSUFFICIENT. If only the schedule log is unreadable, the check continues, but a slot with no run becomes UNVERIFIABLE_LOG_ACCESS instead of MISSING_INVOCATION, because only the log can prove a miss.

API, n8n, Make and AI agents

Start the Actor with the same input JSON from the API, n8n, Make or Zapier. One unreadable schedule does not stop the others.

AI agents can call it through the Apify MCP server:

https://mcp.apify.com?tools=automa-flow/apify-missed-schedule-monitor

The agent should pass the user's own read-only token and treat MISSING_INVOCATION as the actionable miss. SKIPPED_OVERLAP is not a miss.

Limitations

• The first check of a schedule starts from the later of lookbackMinutes and the schedule's last edit, because the configuration before an edit is not known yet.
• A check looks back at most 24 hours. An older gap is reported as UNVERIFIABLE_GAP.
• At most 400 run details are read per check. A run that could not be read leaves its slot SOURCE_CONTRACT_AMBIGUOUS instead of failing the other schedules.
• If the run history in the window exceeds 50,000 runs, the run fails as INPUT_TOO_BROAD instead of silently truncating.
• Daylight-saving gaps and repeated hours are UNVERIFIABLE_DST_EDGE when no run matches.
• Two actions in one schedule that target the same Actor or Task are UNVERIFIABLE_ACTION_MAPPING; the Actor does not guess which action a run belongs to.

How it works

The Actor reads your schedules, expands each cron expression in its IANA timezone, and lists your runs for the window. The run list does not say which schedule started a run, so the Actor reads the details of the scheduler runs that can decide a slot: runs of the same Actor or Task near the slot, and the previous run of an exclusive schedule. Runs of unrelated Actors and Tasks are never read. Checkpoints live in a named key-value store in your account, apify-missed-schedule-monitor-state, keyed by the namespace and the selected schedule IDs; the token is not part of the key. A failed read never overwrites the last good state.

Update history is in the changelog.