Chrono Replay Debugger

DebuggingProfilingTime Travel

Beta Works · surface still evolving · works today, studio surface still evolving

What it is

Distributed and concurrent systems are notoriously hard to debug — bugs only happen under specific timing or interactions between many simultaneous operations. Worse, attaching a debugger or adding log statements often changes the behaviour you were trying to observe. The Chrono Replay Debugger sidesteps this by leaning on the fact that the database already records every committed change as an addressable point on a timeline.

Instead of stepping forward through code, you scrub a slider backward through database time. The debugger reconstructs the state the system held at that instant — the rows, the in-flight transactions, the connections — and renders it for inspection. The application UI built on top of that state re-renders to show you exactly what the user was looking at moments before the failure.

Why it matters

The classic options are bad: production tracing distorts behaviour, and log-grepping after the fact rarely tells you what was actually true at the moment of the bug. A queryable, immutable timeline turns root-cause investigation into ordinary database work.

• Bug-after-the-fact reproduction — drag the slider back five seconds and see the exact state the system held before the failure.
• No observer effect — the timeline already exists from normal operation; replay reads it without disturbing the live workload.
• Heatmap-driven performance triage — watch parallel work execute as a live visualization and spot the saturated stages instead of guessing from a percentile chart.

flowchart LR
  classDef ui fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef db fill:#1f2640,stroke:#00d4ff,color:#00d4ff
  classDef tl fill:#1f2640,stroke:#4ade80,color:#4ade80

  S[Timeline slider<br/>picks an instant]:::ui --> G[Database resolves<br/>the snapshot]:::db
  G --> HIST[Historical state<br/>at that instant]:::tl
  HIST --> R[App re-renders<br/>at that moment]:::ui

How you use it

In normal development, the slider lives at the bottom of the studio. Drag it back to a previous instant and the running application re-renders at that snapshot. Underneath the UI, the slider is just issuing the same temporal queries you can write yourself.

-- What the slider does under the hood: a temporal SELECT
-- against the state you want to inspect.
SELECT id, status, last_actor, last_ts
FROM orders
FOR SYSTEM_TIME AS OF TIMESTAMP '2025-09-14 13:42:05.231';

-- The full history of one row, useful when chasing a bug.
SELECT id, status, last_actor, last_ts
FROM orders
FOR SYSTEM_TIME FROM TIMESTAMP '2025-09-14 13:00:00'
                TO   TIMESTAMP '2025-09-14 14:00:00'
WHERE id = 9087
ORDER BY last_ts;

-- A view used by the studio's heatmap to colour parallel workers.
SELECT worker_id, stage, saturation_pct
FROM system.worker_utilization
WHERE ts > NOW() - INTERVAL '30 seconds';

Every query the debugger runs is plain SQL you can also run from your own code — the studio is a UI on top of the same surface, not a separate API.

Key concepts

Concept	Meaning
Timeline slider	The control that selects a moment to rewind the UI to.
Epoch	A specific point on the database’s monotonic time axis.
Worker heatmap	A live view of parallel workers coloured by saturation.

Notes & caveats

Tip

Pair the timeline slider with the worker heatmap when chasing performance issues: scrub to the moment latency spiked and the heatmap shows you which stage of the pipeline was saturated, instead of having to interpret a percentile chart.

Heads up

The depth of the replay window depends on how much history your deployment retains. Snapshots that have aged out into cold storage are still queryable but may add a small fetch latency to the first replay against that range.

Temporal Tables & Events →

The SQL surface the slider uses behind the scenes.

Storage Lifecycle →

How aged-out snapshots tier to cold storage and stay queryable.

Storage →

How historical state stays durable and addressable.