Reading a run

Umpteenth records every run of a job: its status and cost, each model turn, and each command the agent ran along with the output. Open Runs in the sidebar to find a run, click it to read it, and check the Dashboard for totals across all jobs.

Finding a run

Runs lists every run of every job, newest first, and a job’s own Runs tab shows the same table for that job alone. Narrow it with the Status, Mode, Trigger and Date filters, or type in Search runs, which matches job names and the text of run summaries and errors. A search for rate limit finds the runs whose error mentions one.

The command palette (⌘K or Ctrl+K) finds jobs and runs from any page, including run numbers such as #14 or triage #14.

Run statuses

A run passes through up to four live statuses and ends in one of five final ones. You can stop it in any live status.

A trigger creates a queued run, or a skipped one if another run of the job is active and the job skips overlapping runs. A live run ends as Succeeded, Failed, Timed out or Cancelled, and a scripted run goes back from Verifying to Running when the agent takes over.

Status	Meaning
Queued	The run waits for a free slot, or for the job’s active run to end if the job queues overlapping runs. Each replica executes at most `runs.max_concurrent` runs at once, 3 by default.
Provisioning	Umpteenth prepares the job’s image and the sandbox, then runs the setup script.
Running	The agent works, or a graduated job’s main script runs.
Verifying	Scripted runs only. Umpteenth checks what the main script did, and if a check fails, the run goes back to Running while the agent takes over.
Succeeded	The agent reported success, or the main script passed its checks.
Failed	The agent reported a failure, the run hit its turn or cost limit or the daily spend limit, or a step before the work failed, such as the image build or the setup script. An error that starts with `interrupted:` means the server running it stopped.
Timed out	The run hit its time limit, which includes any wait for the job’s image.
Cancelled	You clicked Stop, or Umpteenth shut down while the run was in flight.
Skipped	A trigger arrived while another run of the job was active, and the job skips overlapping runs.

Managing jobs covers the time, turn and cost limits, and Triggers and schedules the overlap setting.

The run page

Click a run to open its page.

A finished Assisted run: the status, mode, trigger and model under the title, the Duration, Cost, Turns and Playbook stats, and the Timeline with model turns and shell commands

The line under the title shows the status, the mode, the trigger (such as “Retried by Ada Park”), the start time and the model. A scripted run that needed the agent’s help shows the mode Scripted · fell back, or Scripted · handed over if its main script handed a case to the agent on purpose. Below it, four stats sum up the run: Duration, Cost, Turns (the model calls the agent made) and Playbook, the playbook version the run started with. A run that didn’t succeed shows its error in a box titled with its status, such as Failed or Timed out, or the agent’s summary under The agent reported a failure.

Timeline

The Timeline streams the run as it happens, one step per event, each marked with its offset from the start, such as +1m 12s:

Turn 3 is one model call, with its duration and cost.
A shell command shows as a terminal with the command and its output. A red exit N badge marks a command that failed, and timed out or out of memory one that ran out of time or memory.
Verification passed or Verification failed lists each check of a scripted run, and Fell back to the agent gives the reason the agent took over.
Finished or Finished with a failure holds the agent’s summary and outputs, and Error names what stopped the run. Finished with nothing to do marks a successful run that found no work, such as a digest on a quiet day.

To debug a failed run, start at the bottom: find the last command with an exit badge, then read the turn before Finished with a failure. The agent’s dead ends stay in the timeline next to what worked, which makes it more candid than most incident write-ups.

Waterfall

Open the Waterfall tab when a run took four minutes and you want to know where they went. It draws every step that took time on one time axis. A long Provisioning bar points at an image build, a long Setup script bar at a slow setup script, and a column of long model bars at a slow model.

For a quicker answer, hover a finished run’s duration in the runs list or on its page, which splits it into Queue, Provisioning, Model, Tools and Other.

Outputs, Learned and Raw

The Outputs tab collects what the run produced. Its Summary card holds the Markdown summary the agent wrote, or the one a main script set with ump summary, and its Outputs card the structured values the run reported, such as a count or a URL. Artifacts lists the files the run wrote to /ump/outputs, each with a download link. Umpteenth collects up to 50 MiB of them per run, from failed runs too. The tab also shows the Input the run got in /ump/input.json, such as a webhook body, and any Run instructions given through Run now or the API.

Learned shows what reflection took from the run and the playbook changes that came of it, as How jobs learn describes.

Raw holds the run and its events as the API returns them, with Copy and Download JSON for a bug report.

Stop, retry and learn

Stop sits at the top right of a live run’s page. Confirm with Stop run, and Umpteenth destroys the sandbox and ends the run as Cancelled. A queued run never starts and ends at once with “Cancelled before it started”.

Once the run has finished, Retry takes its place and starts a new run of the same job with the same input and run instructions. The new run uses the job’s current playbook and settings. It also follows the job’s When runs overlap setting, so a busy job under Skip skips it and you see the notice Retry skipped.

Learn from this run appears next to Retry if reflection skipped a run that succeeded, failed or timed out, and starts reflection on it. The REST API offers all three actions.

Delete runs

Admins and owners can delete finished runs they don’t want in the history, such as the test runs of a new job. Click Delete on the run’s page, pick Delete from a row’s ⋯ menu in a runs table, or check several rows and click Delete above the table. Stop a live run first, and wait for reflection on a run to finish before you delete it.

Retention

Umpteenth deletes the timeline events and artifacts of runs that finished more than Retention days ago, 90 by default. Admins change the number under Settings → General → Spend and retention. Until someone saves that card, the workspace follows runs.retention_days. The run record stays with its status, summary, outputs and cost, so the runs list and the Dashboard keep their history. A pruned run’s Timeline reads No events.

The Dashboard

The Dashboard, the first item in the sidebar, sums up runs and spend across all jobs over 24h, 7d (the default), 30d or 90d. Each card compares its figure with the previous period of the same length.

The cards count Runs, Success rate, Median duration and Spend. Runs leaves out skipped runs and counts timed-out runs as failed. Spend adds the cost of learning, which covers reflection and the checks of scripted runs, to the cost of the runs themselves. Below the cards, Runs per day charts runs by status and Cost per day charts cost by job.

Running now lists the queued and in-progress runs, and Recent failures the last five runs that failed or timed out, from any date, with their errors.

Getting cheaper lists up to five jobs whose latest three successful runs cost less on average than their first three, such as a job that graduated to a script.