Skip to content

Output and retention

Output arrives as the run goes, has a cap set by the plan, and its text is swept after a while — the run's state and timings are not, and a downgrade deletes nothing you could already read.

It arrives as the run goes

The agent sends output in pieces as it is produced — every few hundred milliseconds, or every eight kilobytes — so a running run's page fills while the process is still going. stdout and stderr are one stream, in the order the command wrote them; anyone wanting them apart redirects them themselves. ANSI colour and emphasis are rendered, other control sequences are not. A running run with no output shows running…, a finished one (no output).

Before the output leaves the host it goes through masking: the values of the secrets the run asked for are replaced in it with ***.

Below the output, a failed run has a red sentence with a cross — that is the agent's verdict, not the command's last line: exit status 1, killed by agent shutdown, this agent has no value for DB_URL. And beside it the exit status, where there is one; a process killed by a signal has none.

The size cap

One run's output is capped in characters, by the plan. Past it Runjet discards further text and leaves one mark in its place:

… output truncated at 1000000 characters …

The run carries on normally — the agent keeps reporting, the command finishes, the verdict and the exit status both arrive. Only the text is discarded. Runjet enforces the cap rather than the agent, because the agent is the thing being limited. In characters and not in megabytes because "1 MB" is a lower bound for a log with accented text, and the mark you will end up quoting says characters.

The window for the text

The text of an output is kept for as long as the plan gives it, and after that a nightly sweep replaces it with a mark:

… output no longer kept …

A mark, not an empty string — "this run printed nothing" and "we no longer keep this run's output" are different things and a reader could not otherwise tell them apart. Runs still going are left alone by the sweep.

Everything else about a run stays for as long as the workspace exists: its state, its trigger, when it was created, when it started and finished, the exit status, the verdict's sentence, the agent. That is what the dashboard, the history and the success rate all read, and it is tens of bytes against up to a megabyte of text. So a plan does not limit how far back you can see; it limits how long you can read the log.

A downgrade deletes nothing you could read

The window is an age, so moving to a shorter one would delete text you could have read the day before — it would charge your change of mind against your history. So moving to a smaller plan writes a time floor into the workspace and the sweep never reaches past it: output older than the floor stays for as long as the workspace exists. The window is a promise about how long output is kept from here on, not backwards.