Scheduled AI Job Not Running? Where to Look First

A scheduled AI job that didn't fire at 09:00 usually says why on its own page: the badge, the Next timestamp, a run status, or the Steps transcript.

Shirley Guo
Shirley Guo
Sep 19, 2026

A scheduled job that didn’t run when you expected has usually left the reason on its own page. The skill is reading it in order.


The 09:00 digest did not arrive, and the instinct is to rewrite the job. Hold off: in Insulin, nothing that fires is invisible. Skipped and rate-limited runs still leave a row, and a failed run keeps the transcript of what it did before it failed. For setting a job up rather than debugging one, see how to schedule a recurring AI agent job.

Where should you look first when a job didn’t run?

Open the job and read four things in order: the Active or Off badge, the Next timestamp, the newest row of the Runs table, and — for a failed run — its Steps tab. An Off job will not fire on its own, a blank Next means the schedule is frozen, and None yet. in the Runs table means the job has never fired.

Symptom, cause, fix: the diagnostic table

Find what you see in the first column; the other two give the cause and the control that fixes it.

What you seeWhat it meansWhat to do
Off badge, or an off tag in the listSwitched off; it will not fire on its ownTurn on the Enable / Disable switch
Run now works, but the schedule never firesRun now bypasses the enabled checkCheck the badge, then Next
It fired at the wrong hourNo timezone: the expression runs on the service’s clockCompare the run’s Started time with the hour you meant; change the hour in the expression
Next is blankDisabled or just re-enabled, so the schedule is frozenEnable it; blank right after re-enabling is expected
The Runs table reads None yet.The job has never firedBadge, then Next; for a push job, check that events arrive
FilteredThe filter returned false, so the run was skippedCompare the filter with a payload the job received
Rate limitedThe job hit 60 runs in an hour, or the organization hit 300The limits are fixed: start the job less often
Run now came back Filtered or Rate limitedRun now takes the real trigger path, filter and limits includedTest the filter with a sample payload, over REST or through the assistant
Run rejected with Job already has an in-flight run.One run at a time, and one is activeLet it finish, or Terminate it
A REST run call answers 400The run endpoint accepts manual jobs onlyUse the trigger endpoint the error names
FailedThe agent encountered an errorSelect the run; it opens on Steps
Several jobs went quiet at onceAI is paused for a billing reason; jobs are refused before the model is calledRead the banner at the top of Settings → Billing
A colleague’s job is missing from your listJobs are private to their creator, organization admins includedAsk the owner

Filters and the full set of run statuses have posts of their own: which events actually run a job, and which get filtered, and how to see past runs of a scheduled AI job.

Why did the job run at the wrong hour?

Because no timezone is attached to a cron expression. 0 9 * * 1-5 means 09:00 on the service’s clock, not 09:00 where you are, and the expression is the whole schedule: no timezone field, no start or end date.

The runs table shows when it actually fired. Each run’s Started time is shown in your own time, so compare it with the hour you meant, while Next counts down to the upcoming run (for example, in 5h). If the hour is wrong, change it in the expression — the Jobs app has no edit form, so ask the assistant or send a PATCH to the REST API — and check Next again. Re-check it after a daylight-saving change, too: an expression on the service’s clock is not guaranteed to follow your local hour.

Why doesn’t Run now prove the schedule works?

Because Run now skips the one check that stops a schedule: whether the job is switched on. Run now is the button on a cron or push job that fires it immediately, as if its schedule or event had arrived. Because it bypasses the enabled check, it works on a switched-off job — handy for testing a paused automation, useless as proof that the schedule will fire.

Everything else matches a real run. Run now takes the same path a real tick or event takes, so it is filtered and rate limited exactly like an automatic run. The in-app button fires with an empty payload; the REST trigger endpoint and the assistant accept a sample payload to exercise the filter.

Running a manual job — with Run, or its REST counterpart, the run endpoint — is the one manual path that skips the rate limit. The run endpoint accepts manual jobs only: on a cron or push job it answers 400, naming the trigger endpoint to use instead. Either way, the in-flight rule holds — one run at a time.

Why was a job rate limited when it barely runs?

Because two limits apply, and only one belongs to the job. Runs that Insulin starts for you — cron ticks and arriving push events — are capped at 60 per hour per job and 300 per hour per organization, over a rolling one-hour window. A run past either is recorded as Rate limited instead of executing.

A job that fires once a morning is nowhere near its own 60, so the organization’s 300 is the likely cause — possibly used up by jobs that, being private to their owners, neither you nor an administrator can see. The limits are fixed, so the fix is fewer starts: a filter on a push job, or a less frequent expression.

How do you read the Steps tab of a failed run?

Select the run: a failed run opens on Steps, where the reason usually is. Steps is the run’s tool-call transcript — which tools ran, in what order, each call’s Args and its Result or Error, and how long each took. It is persisted, not reconstructed, so a run that threw keeps everything it did before it failed. Work back from the last Error and the Args it was sent.

The two empty states differ. This run recorded no steps. means the run did no tool work; No transcript recorded means it predates transcripts or ended before it began work. The Input tab holds what the run received — for a push run, the event payload.

What if the cause isn’t the job at all?

Two causes never show up in a job’s own settings: a billing pause, and a job that belongs to someone else.

AI is paused for the organization

When AI is paused for a billing reason, a request that has not started — a job’s included — is refused before the model is called. If several jobs went quiet at once, read the banner at the top of Settings → Billing first: it names one of four reasons, each with its own fix, and service resumes automatically once the cause is cleared. Adding credit does not clear a spending limit you set yourself; the When AI Pauses documentation covers all four.

The job belongs to someone else

A job is private to its creator: only its owner can see it, run it, edit it, or delete it, organization administrators included. A colleague’s job will not appear in your list or in a channel’s Jobs tab, and while its owner is away nobody else can run it.

Frequently asked questions

Why did my scheduled job run at the wrong time?

Because no timezone is attached to a cron expression, so it runs on the clock of the service rather than yours. Compare past runs’ Started times with the hour you meant, and use Next, which counts down to the upcoming run, to confirm a change.

Does Run now prove a scheduled job will fire?

No. Run now bypasses the enabled check, so it works even on a job that is switched off. It does pass through the filter and the hourly rate limits, exactly like a real tick or event.

What are the rate limits on Insulin jobs?

Runs that Insulin starts for you, from a cron tick or a push event, are capped at 60 per hour per job and 300 per hour per organization, over a rolling hour. The limits are fixed, and a run over either is recorded as Rate limited.

Can an admin see or run a job someone else created?

No. A job is private to the person who created it. Only its owner can see it, run it, edit it, or delete it, and that includes organization administrators.

Why does the REST run endpoint return 400?

Because it accepts manual jobs only. Called on a cron or push job, it answers 400 and names the trigger endpoint to use instead.

Takeaways

  • Read a job in order: the badge, Next, the newest run, then Steps.
  • A cron expression carries no timezone. Check Started and Next, not the digits.
  • Run now skips the enabled check, but not the filter or the rate limits.
  • The limits are 60 runs per hour per job and 300 per organization, rolling and fixed.
  • Only a job’s owner can see or run it — organization administrators included.

For what scheduled AI jobs in Insulin can automate in the first place, start with the product page; the Jobs documentation is the full reference for runs, limits and triggers.

Sources

Primary sources for the platform rules cited above. Last verified September 19, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.

  • Suger docs: Jobs — No timezone field and the Next timestamp, the Active and Off badges, run statuses, the per-job and per-organization hourly limits, Run versus Run now, the in-flight rule, owner-only access, the Steps transcript, and the REST run endpoint's 400 for cron and push jobs
  • Suger docs: When AI Pauses — Requests that have not started, jobs included, are refused before the model is called; the four banner reasons and how service resumes

Browse every post on the Insulin Blog

Stay Updated

Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.