Status › Data & views

Data & views

Everything Slatepipe stores is yours to read without us. This page documents the three static files behind the run-history demo and the two database views the real interface is built on - the same ones your own dashboards should read.

Updated 2026-10-17 · stable within the 0.14 series.

On this page

runs.json
runs.csv
feed.xml
status.json
Database views
Stability promise

`/api/runs.json`

A single object: a meta block, a count, and a runs array. Each run is one execution. Times are UTC ISO-8601. This particular file is demonstration data from a staging install so the screenshots reproduce; a live install emits the same shape.

Field	Type	Meaning
`id`	string	Stable per run, `r-YYYYMMDD-<pipeline>`.
`pipeline`	string	The `--pipeline` identifier. Changing it starts a new history.
`started`	string	UTC timestamp of `run.started`.
`duration_s`	integer	Wall-clock seconds. Zero for a run that never started.
`median_s`	integer	Trailing median over 30 runs, the figure ratio rules compare against.
`status`	enum	`ok`, `slow`, `empty`, `failed`, `timeout`, `missed`.
`rows_in` / `rows_out`	integer	Summed over steps that reported counts; absent steps contribute nothing.
`exit_code`	integer / null	The child's exit status. `null` when there was no process (a missed schedule).
`failed_step`	string / null	Step boundary the run stopped inside, when it stopped.
`host`	string	Where the agent ran.

The status enum is derived, not stored on the wire: empty is an ok exit whose rows_out fell below the row-count rule, and slow is an ok exit past the duration ratio. The agent never sends a verdict; the collector assigns one after each insert.

`/data/runs.csv`

The identical records flattened to one header row and one line per run, for a spreadsheet or a quick awk. Same field names, same order as the table columns, empty cell where JSON has null. It is a convenience mirror; the JSON is the reference.

id,pipeline,started_utc,duration_s,median_s,status,rows_in,rows_out,exit_code,failed_step,host

`/feed.xml`

An Atom feed of announced releases, newest first, each entry carrying the version, date and the change summary. It is the machine-readable twin of the release notes; point a reader at it if you would rather not check the page. Nothing in it calls home - it is a static file served beside the others.

`/api/status.json`

What the status board reads at load. A components array and an incidents array, plus an overall string that is either operational or degraded. The board works without it - the component states are already in the page - but the ninety-day bars and the day counter come from here.

Field	Type	Meaning
`components[].id`	string	Stable key, matches the `data-comp` on the board.
`components[].state`	enum	`operational`, `degraded`, `down`.
`components[].uptime90`	number	Rolling ninety-day percentage, two decimals.
`components[].history`	string	Ninety characters, one per day, oldest first: `u` up, `d` degraded, `x` outage.
`incidents[].state`	enum	`investigating`, `monitoring`, `resolved`.
`incidents[].timeline`	array	Triplets of timestamp, state and the update text, in posting order.

The incident objects here carry the same timeline you see rendered on the history page; that page is the readable twin, this file is the one a monitor of your own would poll.

Database views

Reading the database directly is expected and supported. Two views are the contract; the physical tables under them may be reshaped within a minor series, the views will not.

v_run_summary: One row per run: run_id, pipeline, started_at, duration_s, status, rows_in, rows_out, exit_code, median_duration_s. This is what the overview and the run list read, and what the CSV above is dumped from.
v_step_latest: One row per step of the most recent run of each pipeline: pipeline, step, ord, duration_s, rows. Join it back to v_run_summary on pipeline for a single-run breakdown.

SELECT pipeline, started_at, duration_s, median_duration_s, status
FROM v_run_summary
WHERE status <> 'ok'
ORDER BY started_at DESC
LIMIT 20;

Grant a read-only role on the slatepipe schema and build whatever you like on top. We would rather you query these two than scrape the interface, which is why they are named, frozen and documented here.

Stability promise

Within a minor series - everything tagged 0.14.x - the JSON keys above, the CSV header, the feed structure and the two view signatures do not change. New optional fields may appear at the end; nothing existing is renamed or removed until a minor-version bump, which the release notes call out with the word schema. There is no versioned request path because none of this is a request: they are files on disk.