Run History
Reporting → Run History records every report run, whatever triggered it: a schedule, a job, the webapp, the CLI, or an external system holding a run key.
What a run records
| Field | Meaning |
|---|---|
| Report | Which report ran, and which published version |
| Trigger | Schedule, job, manual, CLI, or run key |
| Agent | Which agent executed it |
| Parameters | The values the run was given |
| Status | Queued, running, completed, or failed |
| Duration | Query time and render time |
| Rows | Rows the query returned |
| Documents | The files produced, with download links |
| Distribution | Per-channel delivery outcome |
| Error | The failure message, when there is one |
Note what is not here: the result set. Run history holds metadata and the finished documents, never the rows. The data stays on the agent.
Downloading documents
Documents are generated and stored on the agent. The download button fetches them from the agent on demand — no object storage required to read a recent report.
How long they stay available is the agent's storage.retentionDays, 30 days by default. After that a download returns 404 unless the document was archived.
To keep documents longer, enable archiving: set storage.archive: true on the agent to upload every generated document to Rynko, or turn on Upload documents on an individual report to force it for that report regardless of the agent default.
Diagnosing failures
A failed run keeps the error from the layer that produced it, which usually points straight at the cause:
Query failures carry the database driver's own message — a missing table after a schema change, a permission the read-only user lacks, or a timeout that means the query needs an index or a narrower parameter.
Render failures mean the data did not fit the template. The usual cause is a query column that was renamed or dropped while the template still expects it.
Distribution failures leave the document intact. The run is recorded with the delivery error and you can download the file or retry the delivery — a bad SMTP password does not cost you the report.
Delivery and run failures also raise in-app notifications, so a schedule that starts failing at 06:00 on Monday does not go unnoticed until someone asks where their report is.
Offline runs
When an agent is disconnected, scheduled runs still execute against locally cached definitions and are queued for reporting. They appear in run history once the agent reconnects, timestamped when they actually ran rather than when they synced.
A gap in run history means the report did not run. A late-appearing run means the agent was offline. The distinction matters when you are working out whether anyone got their report.
Run links
A run link is a signed, expiring URL that serves a run's document. Teams and Slack notifications use them, because a webhook post cannot carry a file attachment.
Following a run link fetches the document from the agent. The file still never passes through Rynko.