Skip to content
Het fundament eronderDurable operations

Control center

Eén scherm voor eigenaren, voor alles wat een mens nodig heeft.

Vastgelopen taken, doodgelopen wachtrij-events, mislukte webhookleveringen, opslagverwijderingen die nooit afkwamen en facturatieachterstand komen samen op één scherm, gegroepeerd per actie die ze nodig hebben. Elke oplossing is één knop die dezelfde bewaakte route draait als het onderdeel zelf, en elke oplossing wordt vastgelegd.

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

Productvoorbeeld

Bekijk het in werking

Dit is hetzelfde visuele component als in de ingelogde applicatie, met voorspelbare voorbeelddata.

Scenario
Voorbeeldscherm
Thema van voorbeeldoppervlak
Voorbeeldmodus

Attention required

An open incident, a delayed job and a dead queue event, all scoped to one organization.

Inerte voorbeelddata · geen netwerktoegang

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.

Voorbeeld gereed

Het probleem dat dit oplost

Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw, en anders.

Fixing it over a database console

Someone reports an export that never arrived, and the only way to look is a hand-written query at eleven at night. There is no single view of what actually needs a person right now.

The fix that causes the next problem

Re-firing a delivery from a console or flipping a status column by hand skips every check and leaves no trail. It works until the day it makes a bigger mess than the one it cleaned up.

Failures scattered across tools

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

Kernpunten

Waarom dit belangrijk is

One screen for trouble

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

Safe retries only

Every fix runs through the same protected command the feature uses. Clicking twice cannot run it twice.

A record of every fix

Each action stores who did what and when, and is tracked until it genuinely settles or fails.

Hoe het werkt

Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.

  1. 1

    Owners only

    The server resolves the active organization and checks who you are. Anyone who is not a current owner gets a 404, not a hint that 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 owning feature uses. The action, its receipt and its audit record commit together.

  4. 4

    Every fix is watched to the end

    A reconciler follows each action until it settles or fails, and the page labels how fresh its own data is rather than implying it is live.

Technische garanties

Wat dit wel en niet belooft

Veiligheidsgrens

Het scherm is alleen voor eigenaren, beperkt tot één organisatie, en toont nooit ruwe payloads of providerfouten. Gezondheidscontroles melden alleen wat ze hebben geverifieerd, dus wat niet is ingesteld of verouderd is, blijft niet geverifieerd in plaats van groen te worden.

Implementatiebewijs

De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:

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

Veelgestelde vragen

Waar Control center op rust

De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.