FENWRIGHT

How it works

Four steps between a page and a fix

Nothing is proxied and no traffic changes path. The recorder writes what your services already say; Fenwright keeps it in order and folds it into state when you ask.

Hands typing on a dark laptop keyboard

Install the recorder

A library, not an agent. It writes the events your service already emits — requests, queue messages, database calls, deploy markers — and ships them in batches off the request path.

npm install @fenwright/recorder

record({ service: 'checkout-api', key: process.env.FENWRIGHT_KEY,
         redact: ['card.pan', 'customer.email'] });
Fibre patch cables plugged into a rack panel

Every event, in order

Events from every instance land in one ordered log per service, stamped to the microsecond. Fields you listed for redaction never leave your process.

t+10:10  queue   depth crosses the 200 alarm line
t+13:20  worker  worker-6 recycled on the same deadline
t+15:05  edge    edge starts shedding 3% of POST /orders
A person at a desk seen from above, one hand on a white keyboard

Replay any hour

Open a window in the browser and drag the head, or pull it to your laptop and run it against your own code. The state at every offset is folded from the log, so it is the same every time.

fenwright pull checkout-api --window 02:00-03:00 --out incident.ndjson
fenwright replay incident.ndjson --at 20:15
A hand drawing a diagram with a blue marker on a whiteboard

Bisect to the cause

Diff a bad hour against a good one and bisect halves the window until it finds the first event after which the two can no longer be explained by each other.

fenwright bisect incident.ndjson --against last-tuesday --key order_id
→ first divergence at t+06:42  db  slow query orders_by_customer

One incident, three moments

The demo recording on the home page is INC-2291: 26 events from checkout-api, Tue 02:00–03:00 UTC. These are the offsets the write-up cites.

  1. t+10:10

    The alarm fires

    Queue depth crosses 200. Everything before this is the cause; everything after is the damage.

    queue 216 · workers 7 · p95 480 ms · failed 4 · degraded

  2. t+27:00

    Bisect names the cause

    Replaying last Tuesday against tonight points at one slow query and one missing index.

    queue 426 · workers 4 · p95 1180 ms · failed 84 · degraded

  3. t+58:00

    Closed against the recording

    The fix ships with the index in its migration. The write-up cites offsets, not recollections.

    queue 30 · workers 6 · p95 214 ms · failed 84 · steady

The published limits

Every fixed number the product promises. If a figure is not here, it is not a promise.

WhatLimitNote
Events per second, per service40,000Sustained; bursts to 120,000 for 60 s
Event size256 KBLarger payloads stored by reference
Replay window24 hoursLonger windows replay in consecutive passes
Replay start1.9 sp95, measured over the last 90 days
Recorder overhead< 0.3 msp99, flushed off the request path
ExportUnlimitedNewline-delimited JSON, gzip
DeletionWithin 1 hourOn request and on cancellation
Ingest availability99.9%Per calendar month, or the next month is free

See your own hour tomorrow

Install the recorder on one service today. Tomorrow morning the night is on file, ready to replay.

npm install @fenwright/recorder