How to See Past Runs of a Scheduled AI Job

A scheduled agent does its work while you are asleep, on a plane, or in a meeting. The only thing standing between “it ran” and “I trust it ran” is a record you can open — run by run — of what it actually did.

The moment you put an agent on a schedule, you give up watching it. That is the whole point: the month-end sweep, the Monday digest, the overnight sync review all move off your to-do list and onto a timer, and you stop being present for any of them. What you get back has to be worth the trust — and trust in an unattended process is not a feeling, it is a record you can read after the fact.

That record is the runs table. Since late July 2026 every Insulin job has a single, unified detail page, and on it a table of every past execution — see the changelog entry that shipped it. This post is about how to read that table, and how to use what you see to make the next run better.

How do I see past runs of a scheduled AI job?

Open the job’s detail page. Every job in Insulin has one, and on it is a runs table — one row per execution, newest first, listing when each run started, its status, and its duration. Every trigger the job fires — a scheduled tick, a one-time kickoff, or a business event — creates a run record there, so the table is the full history of what that job has ever done.

The table pages through older runs as you scroll, so a job that has fired every morning for a month is all there in one place: no separate log to hunt for, no guessing whether last Tuesday’s run happened. If it ran, it is a row.

What each row tells you before you open it

Three columns answer the first three questions you have about any run — and you can answer them without opening anything.

Started — when did this fire? A scheduled job should have rows at the cadence you set. A gap where a row should be is itself a finding.
Status — did it work? Insulin records the full outcome, not just success or failure: Completed, Failed, Pending, Running, Cancelled, Filtered, and Rate limited. A Filtered or Rate limited run is still a row — the event arrived and Insulin recorded the decision, so nothing silently disappears.
Duration — how long did it take? A run that suddenly takes far longer than its neighbours is worth a look before it becomes a failure.

Read down the status column and you have the health of the whole job at a glance. A clean stripe of Completed is exactly what an unattended job is supposed to look like.

Reading a single run

To see what a run actually did, expand its row. It opens in place to that run’s result — the output the agent produced — or, if it went wrong, the error it hit. For a run that fired from a business event, the expanded row also shows the event payload it received: the exact thing that triggered it.

That last detail matters more than it sounds. When an event-driven run does something surprising, the first question is never “what did the agent do wrong” — it is “what did the agent actually receive.” Having the triggering payload sitting next to the result turns a debugging session into a five-second read: you can see the input and the output side by side and tell immediately which one is the problem.

This is the same principle that makes a grounded agent’s citations worth reading: the value is not that the output looks right, it is that you can check it against what it was working from.

From a run to a better task

The runs table is not just a record — it is the feedback loop. The Jobs product page puts the last of its four steps plainly:

Review the runs — Read the output, adjust the task, and let the job keep going.

That sentence is the whole method. A job is not something you set once and forget; it is something you set, watch for a few runs, and correct. You read the first real outputs, notice where the agent misread the task or formatted the result wrong or flagged the wrong things, tighten the plain-English instructions, and let it keep running. The next morning’s run reflects the edit — and you check that run too.

Because the history persists, you can see the effect of a change instead of guessing at it. The run before your edit and the run after it are two adjacent rows; you tune the task against evidence, not against a memory of how the last run looked.

Why the history is the thing that makes automation safe

Leaving an agent to run unattended is only responsible if someone can reconstruct what it did. An agent that inherits your integration scope and reads from your connected systems is doing real work in your name — and “we automated it and stopped thinking about it” is not a story anyone wants to tell when a downstream number looks wrong.

The runs table is the answer to that. It means an unattended job is auditable after the fact:

Nothing runs invisibly. Every trigger — including a Filtered or Rate limited one — is a row. The absence of a run is as visible as its presence.
Every outcome is on the record. A Failed run is not a silent gap; it is a row you can open to the exact error.
The trigger is preserved. For event-driven runs, the payload that started it is stored with the result, so a surprising outcome is traceable to its cause.
The history is durable. You can look back across a job’s whole life, not just its most recent tick, which is what lets you spot a pattern rather than react to a single bad morning.

An unattended agent you cannot inspect is a liability. An unattended agent whose every run you can open, one by one, is just a colleague who works while you sleep and leaves clear notes.

Frequently asked questions

How do I see past runs of a scheduled AI job in Insulin? Open the job’s detail page. It has a runs table listing every past execution — newest first — with when each run started, its status, and its duration. Every trigger the job fires creates a row.

What does the runs table show for each run? Each row shows the run’s Started time, Status, and Duration. Expand a row to read that run’s result, its error if it failed, and — for an event-driven run — the event payload that triggered it.

What run statuses can a job have? Insulin records Completed, Failed, Pending, Running, Cancelled, Filtered, and Rate limited. Even filtered or rate-limited events stay in the history, so no trigger disappears silently.

Can I see why an unattended job produced a particular result? Yes. Expand the run to see its output, or its error if it failed. For an event-driven run, the triggering payload is stored alongside the result, so you can trace the outcome to its cause.

How do I improve a job after reviewing its runs? Read the output of the first real runs, adjust the task’s plain-English instructions, and let the job keep going. Because the history persists, you can compare the run before your edit with the one after it.

Takeaways

Every Insulin job has a detail page with a runs table — one row per execution, showing Started, Status, and Duration.
Every trigger creates a record. A scheduled tick, a one-time run, and a filtered or rate-limited event all become rows, so nothing runs invisibly.
Expand a row to read that run’s result, its error, or the event payload that triggered it — the input and output, side by side.
The runs table is the feedback loop: read the output, adjust the task, let the job keep going, and check the next run against the last.
A durable run history is what makes an unattended agent auditable rather than a black box.

The runs table turns “the agent ran overnight” into “here is exactly what it did, run by run.” Explore Insulin jobs, see the agents that power them, or read the Jobs documentation for the full anatomy of a run.