Operational evidence beyond structural links
Operations & Reliability connects these panes to graph evidence, instance diagnostics and Shadow comparison. The chain below resolves declarations and provider reads; it does not yet prove a particular request traversed each resource. Exact observed-run joins need artifact/activation identity, context propagation and coverage. Baseline/candidate traces stay separate and are linked by a paired comparison record. Existing ClickHouse product analytics remain in place.
Reaktor Workbench Links
Reaktor Desktop's panes each read one part of a product: the running app's graph, the phones, the cloud accounts, the databases, the deploys, the product analytics. On their own they answer questions about their part. Connected, they answer the questions that cross parts: which database does this screen depend on, which screens break if this worker fails, which worker served this failing request, what is live right now.
Status: built on 30 September 2026 and checked against BestBuds: the app graph, the Cloudflare and cluster declarations, and the production Data targets.
The chain
Every link follows one chain, in both directions:
screen → graph node → service → worker → store → Data target
- A screen or repository in the Graph reaches the service nodes it depends on through its wires.
- A service node knows its base URL, and its host is routed to the Cloudflare worker that serves it,
so
social.bestbuds.airesolves tosocial-service. A gateway host is still followed through its service bindings, by first path segment. BestBuds retired itsedge.bestbuds.aigateway on 1 October 2026. - A worker's bindings are its stores: D1 databases, Durable Objects, R2 buckets, KV namespaces, and Postgres through Hyperdrive. ClickHouse and Memgraph are reached through VPC services.
- Each store maps to the Data pane's target for it: D1 and Durable Objects by the worker and binding that own them, Postgres and ClickHouse by their environment's connection.
Where you see it
| Pane | What it shows from the others |
|---|---|
| Graph | The inspector's Runs on (for a service) or Backed by (for anything that depends on one): the worker, how it was reached, its last deploy and 24-hour traffic when Cloud has been read, and each store with a link to it in Data. |
| Cloud | The inspector's In the app: the app services a worker serves and the screens that depend on them, each a link into the Graph, plus the worker's stores as links into Data. |
| Data | A Used by line under the header: the workers bound to the selected database, the app services behind them, and how many screens depend on it. |
| DevTools | Each network request says which worker served it, and which app service sent it when only one service uses that address. |
| Deploy | A Live tab: every worker with its environment, last deploy, author, source, requests and error rate over 24 hours and the app services it serves; every cluster workload with its readiness and images. It reads what the Cloud pane last read, and can start that read. |
| Analytics | Live product analytics from ClickHouse, through the Data pane's read-only connection. Screens in the events link to the matching screen in the Graph. |
Every link opens its target in place: a graph node is revealed and selected, a cloud resource is selected on the Cloud map, a Data target is selected in Data.
Product analytics
The Analytics pane reads bestbuds.analytics_events in ClickHouse through the same bounded, read-only
session the Data pane uses. Reading needs a click, like the Cloud pane, and the results stay while you
move between tabs.
- Performance: events, people and sessions over 30 days; events per day; each event's count for the last seven days against the seven before; platforms and builds; screens viewed.
- Funnels: people reaching each step of onboarding, chat and campaigns.
- Cohorts and Retention: people grouped by the first day they were seen in the last 60 days, and whether they came back the next day or a week or more later.
- Findings from the data itself: a platform whose events carry no app version, onboarding that sends no events while people are active, and session counts high enough to mean the session id is regenerated too often.
For coding agents
Reaktor Desktop's MCP server has a system_trace read. Given a graph node, it returns the services,
workers and stores behind it. Given a URL, it returns the worker that serves it. Given a worker, store
or Data target, it returns the workers, app services and screens that depend on it. app_graph_node
and the Cloud reads answer within their own parts.
Limits
- Links are resolved from the repository's declarations until Cloud has read the accounts; after a read they also carry live deploys and traffic.
- A service node without a base URL links to a worker only when a worker has its name, such as
people-serviceforPeopleServiceNode. In BestBuds, Groups, People, Profile and the inbox call the social and notification services through other clients inside the app, so they link to no worker yet. - R2 buckets and KV namespaces have no Data target yet, so they link to Cloud instead.
- The gateway rule reads the first path segment only, and relies on bindings named
<SEGMENT>_SERVICEor<SEGMENT>. - A base URL decides the worker, and so its environment. A name match prefers the workbench's environment. Stores are matched to the Data targets of their worker's environment.
Next
- Errors and Crashes from the phones' Measure data and the workers' error rates, on the same chain.
- A deploy marker on Analytics and Telemetry charts, from the Deploy pane's live read.
- Tests linked to the graph nodes and screens they cover.
- Auth principals linked to their BestBuds user rows in Data.