Sessions
A session is one run of one process. It starts at enable() and finalizes at process exit (or an explicit disable()). Each session gets a directory under .slomo/sessions/ named <timestamp>-<id> containing its metadata and timeline.
Session metadata records the execution context:
argv, cwd, Python version, hostname, pid- exit status (clean exit vs. crash)
- optional
labels you pass to enable(labels={"service": "checkout"})
forked_from — set when a forked child starts its own session
List and inspect them with the CLI:
Everywhere the CLI takes a session id, a unique prefix is enough — slomo session show a1b2 works.
Events
Every recorded activity is one event: a frozen, typed record appended to the session’s timeline.jsonl.
timestamp is epoch nanoseconds.span_id / parent_span_id link events into a call tree — this is what slomo session inspect renders and what lets slomo doctor reconstruct the path to a crash.payload is type-specific and passes through truncation and redaction before it is written.
Event types
Severity
Each event carries a severity: debug, info, warning, error, or critical. Severity drives:
slomo timeline --errors (warnings and errors only)- backpressure policy — under queue pressure, low-severity events are dropped first; errors are the last to go
Traces and spans
Function events form spans: function.enter opens a span, function.exit closes it, and nested calls carry parent_span_id. Async code propagates span context across await boundaries, so a span tree of an asyncio app reads the way the code logically executed, not the way the event loop interleaved it.
Where events go from here
Events are raw material. The issue engine turns exception events into deduplicated, classified issues; search and timeline let you slice events directly; replay plays them back in order.