Concepts

Event log

Trace any run back to exactly what started it - every ingested event is kept with what it triggered, queryable and streamable live.

Duraton keeps a durable event log: every event it ingests is recorded together with what it triggered. Triggers are the other half - what starts a workflow.

What's recorded

An event reaches the log two ways: an external POST /events (source: "api") or a workflow's step.emit (source: "emit"). Each record carries the event (name, app, data), when it arrived, and the outcome - the waiters it resumed and the per-workflow fan-out:

{
  "id": "9f2b…",
  "name": "ticket.created",
  "app": "support",
  "source": "api",
  "data": { "ticketId": "T-421", "subject": "Charged twice" },
  "receivedAt": "2026-06-15T09:00:00Z",
  "woke": 0,
  "triggered": [
    { "workflow": "fulfillment", "runId": "01H…" },
    { "workflow": "audit", "runId": "01H…" }
  ]
}

An event that matched nothing is still recorded with an empty triggered - so a fire-and-forget event that hit no workflow is visible, not lost. A cron firing is not an event: it starts a run directly, so it shows up in runs, not here.

Reading it

GET /events                 # newest first; filter with ?app= ?name= ?limit=
GET /events/{id}            # one event
GET /events/stream          # live tail (Server-Sent Events)

The console's Events view lists the log and live-tails the stream. The stream is a best-effort live view - a slow or reconnecting client can miss events; GET /events is the complete record.

Recording is best-effort on the ingest path: if the log write fails, event delivery still succeeds (the runs are already durable). The log is not auto-pruned, and listings return a bounded page.

See the events example running end to end in Examples.

On this page