System Logs
Admin → Platform Settings → Logs (/admin/platform-settings/logs) is the platform-wide diagnostic log: what the database migrations, the background workers and the stored functions wrote while running.
Requires the perm:system:status permission. There is no admin bypass.
This is not the Audit Trail. The Audit Trail answers "who changed this record"; System Logs answers "what did the platform do, and what went wrong".
What you see
Five stat cards across the top count the entries at each level for the current filters — Debug, Info, Warning, Error, Critical.
The table below lists the matching entries, newest first:
| Column | Contents |
|---|---|
| Time | When the entry was written |
| Level | DEBUG, INFO, WARNING, ERROR or CRITICAL |
| Source | What wrote it — a worker name, a stored function name, a migration |
| Message | The log line |
Expand a row to see its context: the structured JSON the writer attached. When the entry carries a Python traceback, the expanded row shows it in full, with a copy button.
Filtering
| Filter | Notes |
|---|---|
| Minimum level | Shows that level and everything more severe — set it to Warning to hide routine chatter |
| Source | Pick one source from the list of sources actually present |
| Request ID | Exact match on context.request_id. Letters, digits, ., _ and -, up to 64 characters |
| Search | Case-insensitive substring across message, source and context |
| From / To | Period bounds |
Clear filters resets everything. Filters live in the URL, so a filtered view can be pasted into a ticket.
Two shortcuts save typing:
- A request ID chip inside an expanded row filters to that request in one click — paste the ID off an API error toast to see everything that one request did.
- The Workers screen links straight into this page pre-filtered to a worker, and pins the level to ERROR when that worker is unhealthy.
Supporting a customer
- Set Minimum level to Warning or Error and widen the period to cover the incident.
- Narrow by Source if you already know which worker or function is involved, or by Request ID if the customer gave you one from an error message.
- Read the context and traceback on the failing entries — that is usually the whole diagnosis.
- If you need to hand the evidence over, use Download logs.
Download logs produces a .zip for the currently active filters, containing system_logbook.jsonl (one JSON object per entry) and a manifest.json recording who generated it, the period, the filters applied and the row count. An export is capped at 500 000 rows; beyond that it is refused and the manifest would mark the bundle truncated, so narrow the period or the filters first. Every download is itself recorded in the Audit Trail.
Retention
Log entries do not accumulate forever. The retention worker prunes them:
| Parameter | Default | Effect |
|---|---|---|
RETENTION_LOG_DAYS | 30 days | How long entries are kept |
RETENTION_LOG_DEBUG_DAYS | 7 days | DEBUG entries are dropped earlier; 0 disables the separate prune and keeps them until RETENTION_LOG_DAYS |
Both live on System Parameters. Lowering either permanently deletes older entries — collect a download before you shorten a window you may still need.
Turning on Debug logging (globally, or per worker on the Workers screen) increases log volume and disk usage considerably. Turn it off again once you have what you need.
Related
- Workers — health of the background workers that write most of these entries
- Audit Trail — per-record change history, a different log
- System Parameters — retention windows and the global debug flag