flightrec
Documentation

The flight recorder for Next.js.

Flightrec records a full server→client session as a replayable trace and lets you scrub it on one timeline. This is how it's put together.

Introduction

Most debuggers show you logs after the fact — disconnected lines you have to correlate by hand. Flightrec shows you the whole causal chain of a request, step by step: the Server Action that ran, the cache tag it invalidated, the redirect, the RSC frames that streamed, and the client React tree they patched.

It's built for the Next.js App Router and React Server Components — the parts of the stack that are hardest to reason about precisely. Open source, MIT-licensed.

Pre-release. The inspector is live — try the demo. The recorder that captures your own app is in active development. Join the waitlist for early access.

Quick start

The package isn't published yet, but you can explore the inspector today.

# coming soon
npm i flightrec

Right now, the fastest way to get a feel for it:

  1. Open the live inspector — it boots with a recorded "create blog post" session.
  2. Scrub the timeline (drag, or ← / → / space) and switch modes in the header.
  3. Hit export, then drag the .frec file back onto the card to reload it.
Want a real trace? Record one in the playground — it runs a live Server Action through the recorder and hands you a .frec to drag into the inspector.

The trace model

A session is an ordered list of events. Each event carries a tick (a discrete step) and a phase. The whole inspector is derived from a single number — the current tick — so there's no state to keep in sync.

The 12 phases group into 6 planes, the swim-lanes you see on the timeline:

PlanePhases
useruser-input · client-navigation
actionserver-action:start/end · cookies:mutate · headers:mutate
cachecache:update-tag · cache:revalidate-tag
netredirect
rscrsc:chunk
treetree:diff

The inspector

The inspector lays the session out in five regions around a shared scrubber:

  • ① Timeline — the spine; one lane per plane, a draggable playhead.
  • ② Event index — every event as a list, with plane filters.
  • ③ Center view — the selected mode (below).
  • ④ Context panel — source map, cache tags + outcome, mutations.
  • ⑤ Raw tray — the underlying TraceEvent JSON.

The center view has five modes:

  • timeline — synchronized plane panes (what happened on each).
  • diff — only what changed on the current tick (before → after).
  • payload — parsed RSC/Flight frames, op by op.
  • causality — the cause → effect chain across planes.
  • presentation — a narrated, demo-friendly walkthrough.
See it in action in the live demo → switch modes in the top bar and press play.

The .frec format

A .frec file is a session serialized to JSON, validated on the way in by a Zod schema — drop a malformed file and you get a clean error, never a crash. Export the current session to share a bug, or drag any .frec onto the inspector to replay it.

{
  "id": "ses_8f31a0",
  "schemaVersion": 1,
  "route": "/posts/new",
  "nextVersion": "16.2.6",
  "startedAt": 0,
  "events": [ /* TraceEvent[] */ ]
}

Roadmap

  • Foundations — trace schema + golden fixtures. shipped
  • Inspector MVP — 5 regions, 5 modes, .frec I/O. shipped
  • The recorder — App Router instrumentation that captures your real app. in progress
  • Checkpoints & AI — jump anywhere instantly; AI summaries via MCP. planned

FAQ

Is it open source?

Yes — MIT-licensed, built in public on GitHub.

Does it support the Pages Router?

The focus is the App Router and React Server Components, where time-travel adds the most clarity.

What's the runtime overhead?

Recording is opt-in and dev-first. The trace is a compact event log; heavy payloads are referenced lazily, not inlined.

Built in the open. Watch it take shape.

The demo above runs on synthetic data today — the recorder, inspector, and MCP server are landing phase by phase.