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.
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.
Product example
This is the same visual component used by the authenticated app, rendered with deterministic sample data.
See an open incident, a delayed process, and a dead outbox event in the same tenant-scoped workbench.
Inert sample data · no network access
Owner-only, tenant-scoped operational signals.
Stable fingerprints group recurring conditions; acknowledgements, resolutions, and linked recovery actions remain durable.
Bounded tenant records and safe failure classes only. Provider payloads, response bodies, object names, and raw errors stay hidden.
Recent commands show accepted work through terminal settlement. Trend buckets contain counts only, never identifiers or provider payloads.
Configuration and runtime evidence are separate. “Not verified” never implies that credentials or the live provider are healthy.
Preview ready
Without a shared foundation, every team rebuilds these edge cases — differently.
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.
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.
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
Failed jobs, dead work, webhook errors, storage issues, and billing backlog are grouped by the action each one needs.
Every fix runs through the same guarded path the feature itself uses. Clicking twice can't run it twice.
Each action records who did what and when, and gets tracked until it actually settles.
The mechanism end to end, as implemented in the repository.
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.
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.
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.
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
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.
The boundary above is code, not a claim. These files carry the contract:
src/modules/control-center/MODULE.mdsrc/modules/control-center/server.tssrc/modules/control-center/operations.server.tsThese capabilities share contracts and boundaries with this one.
The docs describe the same contracts this page demonstrates.