Skip to content
Run the businessDurable operations

Control center

When production breaks, fix it with one safe click.

Stuck jobs, failed webhooks, and dead work all show up in one owner-only screen. Each one comes with a safe retry button. No SSH sessions, no poking the database by hand.

1
database step per fix
8
items max per lane, so it stays readable
0
raw payloads shown on screen

Product example

See it working

This is the same visual component used by the authenticated app, rendered with deterministic sample data.

Scenario
viewport
surface theme
mode

Attention required

See an open incident, a delayed process, and a dead outbox event in the same tenant-scoped workbench.

Inert sample data · no network access

Control center

Owner-only, tenant-scoped operational signals.

Last successful read 8:05:00 AM

Operational alerts

1 active

Tenant summary

Members
14
Organization-wide memberships
Projects
6
Active projects
Plan
Scale
active
Active work
2
Queued, running, or waiting

Incident lifecycle

Stable fingerprints group recurring conditions; acknowledgements, resolutions, and linked recovery actions remain durable.

1 active

Durable process exceeded its heartbeat objective

processes · 1 affected · seen 2 times · 0 linked actions

processes:heartbeat-delayed:notes.bulk-archive

open

Recovery workbench

Bounded tenant records and safe failure classes only. Provider payloads, response bodies, object names, and raw errors stay hidden.

Processes succeeded
48
Processes failed
1
Dead outbox
1
Dead webhooks
0
Failed deletions
0
Processes requiring attention
Latest confirmed milestone and registered error reference.
Transactional publication
Dead events can be requeued without exposing or editing payloads.
  • app/notes.bulk-archive.requested

    Publication attempts exhausted · 8 attempts · 8/13/2026, 7:50:00 AM

Webhook delivery
Eligible failures replay through the original signed delivery boundary.

No records require operator attention.

Object settlement
Retry exhausted deletion or explicitly remove quarantined bytes.

No records require operator attention.

Commercial pressure
First-party usage ledger and provider reconciliation state.
Manage billing
Active projectsenforced

6 / 25

x

Provider reconciliation

0

queued or publishing usage events

Settlement and seven-day trend

Recent commands show accepted work through terminal settlement. Trend buckets contain counts only, never identifiers or provider payloads.

webhook.replayRequested 7:40:00 AMsettled
08-07
31/1
08-08
38/1
08-09
44/0
08-10
42/1
08-11
47/1
08-12
51/0
08-13
48/1

Succeeded processes / failed processes plus webhook and storage failures.

Integration readiness

Configuration and runtime evidence are separate. “Not verified” never implies that credentials or the live provider are healthy.

Preview ready

The problem this solves

Without a shared foundation, every team rebuilds these edge cases — differently.

Debugging production over SSH

A customer reports a stuck export. The on-call answer is log grep and hand-written queue queries at 11 p.m. There's no single view of what actually needs an operator right now.

The fix that causes the next incident

Re-firing a webhook from a REPL or flipping a status column in psql skips every safety check and leaves no trail. It works, until the day it quietly creates a bigger mess than the one it fixed.

Failures scattered across five tools

Dead jobs in one dashboard, failed webhooks in another, stuck uploads in a third. Nothing connects a failure to the fix that handled it, so the same fire gets fought twice.

Highlights

Why it matters

One screen for trouble

Failed jobs, dead work, webhook errors, storage issues, and billing backlog are grouped by the action each one needs.

Safe retries only

Every fix runs through the same guarded path the feature itself uses. Clicking twice can't run it twice.

A paper trail for every fix

Each action records who did what and when, and gets tracked until it actually settles.

How it works

The mechanism end to end, as implemented in the repository.

  1. 1

    Owners only

    The server resolves the active company and checks who you are. Anyone who isn't a current organization owner gets a 404, not a hint the page exists.

  2. 2

    Trouble is sorted into lanes

    Failures are grouped by the action they need and capped at eight per lane. Details are reduced to safe summaries; raw payloads and provider errors never reach the screen.

  3. 3

    Fixes reuse the safe path

    Retry, requeue, and replay call the same protected command the feature itself uses. The action, its receipt, and its audit record all save together in one step.

  4. 4

    Every fix is watched to the end

    A background check tracks each action until it truly settles or fails, and the screen tells you how fresh its data is instead of faking it.

Engineering guarantees

What this does and does not promise

Safety boundary

The real screen is owner-only, scoped to one company, and never shows raw payloads or provider errors. The public demo shows sanitized sample data, and the reviewed migration must be applied before you turn this on.

Implementation evidence

The boundary above is code, not a claim. These files carry the contract:

  • src/modules/control-center/MODULE.md
  • src/modules/control-center/server.ts
  • src/modules/control-center/operations.server.ts
Questions

Frequently asked questions

Build on the control center foundation

The docs describe the same contracts this page demonstrates.