Every production question,
answered in one command.

Every request is recorded automatically.

The Flux runtime captures a complete record of every request as it happens — gateway auth, function spans, every database query, tool latencies, async job hand-offs. Whether your function runs on Deno V8 (TypeScript) or Wasmtime (Rust, Go, Java, Python, PHP, AssemblyScript) — same recording, same traces.

# Every request produces:

  trace_requests      → span tree (gateway to db)
  state_mutations     → every row change + request link
  execution_spans     → timing, errors, tool calls

# Nothing to configure. Zero SDK changes.
# The runtime records it all.

$ flux trace debug 550e8400

  Step 1/4  gateway
  ─────────────────────────────────────
  Input:   POST /signup  { email: "a@b.com" }
  Output:  { tenant_id: "t_123", passed: true }
  Time:    4ms

  Step 2/4  create_user
  ─────────────────────────────────────
  Input:   { email: "a@b.com" }
  Output:  { userId: "u_42" }
  Time:    81ms

  ↓ next  ↑ prev  e expand  q quit

Step through any production request.

flux trace debug <id> opens an interactive terminal UI where you can navigate each span of a production request. See the exact input and output at every step — what the gateway received, what the function returned, what the database wrote. All from the actual production execution.

See every change ever made to a row.

flux state history shows every INSERT, UPDATE, and DELETE on any row, linked back to the request that caused it. flux state blame shows which request owns each column's current value. Instantly answer "who or what set this field to this value?"

$ flux state history users --id 42

  users id=42  (7 mutations)

  2026-03-10 12:00:00  INSERT  email=a@b.com, plan=free
  2026-03-10 14:21:59  UPDATE  name: null → Alice Smith  req:a3c91ef0
  2026-03-10 14:22:01  UPDATE  plan: free → pro           req:4f9a3b2c
  2026-03-10 14:22:01  UPDATE  plan: pro → null  (rolled back)  req:550e8400

$ flux state blame users --id 42

  email    a@b.com     req:4f9a3b2c  12:00:00
  plan     free        req:550e8400  14:22:01  ✗ rolled back

$ flux incident replay 14:00..14:05

  Replaying 23 requests from 14:00–14:05…

  Side-effects: hooks off · events off · cron off
  Database writes: on · mutation log: on

  ✔  req:4f9a3b2c  POST /create_user   200  81ms
  ✔  req:a3c91ef0  GET  /list_users    200  12ms
  ✗  req:550e8400  POST /signup        500  44ms
     └─ Still failing: Stripe timeout

  23 replayed · 22 passing · 1 still failing

Test your fix against the exact incident.

flux incident replay re-executes all requests from a time window against your current code. Outbound side-effects are disabled — no emails, no webhooks, no Slack. Database writes and mutation logs run normally. After your commit, replay the incident to confirm the fix before deploying.

Find the commit that introduced the bug.

flux bug bisect binary-searches your git history comparing trace behaviour before and after each commit. It automatically identifies the first commit where a given request started failing. Like git bisect, but for production behaviour rather than a test suite.

$ flux bug bisect --request 550e8400

  Bisecting 42 commits (2026-03-01..2026-03-10)…

  Testing abc123…  ✔ passes
  Testing fde789…  ✔ passes
  Testing def456…  ✗ fails

  FIRST BAD COMMIT
  def456  "feat: add retry logic to stripe.charge"
  2026-03-08 by alice@example.com

  → Compare before/after:
     flux trace diff abc123:550e8400 def456:550e8400

upstream existing_api {
  server 127.0.0.1:3000;  # Express / FastAPI / Rails
}
upstream flux_api {
  server 127.0.0.1:4000;  # Flux
}

server {
  listen 443 ssl;

  # New endpoints → Flux
  location /api/signup  { proxy_pass http://flux_api; }
  location /api/orders  { proxy_pass http://flux_api; }

  # Everything else → existing stack
  location /api/        { proxy_pass http://existing_api; }
}

// All in the same process:

  Gateway  ── in-memory dispatch ──  Runtime
     │                                  │
     │    no HTTP hops                   │
     │    no serialization               │
     │    no service mesh                │
     │                                  │
  Data Engine ── same Postgres txn ──  Queue

// Mutation log = 1 extra INSERT
// in the SAME transaction as your write.
// No extra round-trip. No eventual consistency.