Operations
Service-by-operation drill-down — the same screen as "service detail" but pivoted to one specific endpoint (e.g. `POST /checkout`).
The Operations console is the per-endpoint health view — latency, errors, and throughput for one route (POST /checkout), not just the service as a whole.
What it is
The Operations console is the per-endpoint view. Where service detail answers "how is checkout-api overall?", Operations answers "how is POST /checkout on checkout-api?".
Reach it by:
- Clicking any row in the Operations table on a service detail page.
- Sidebar → Operations → pick a service → pick an operation.
- A deep link from an alert or incident, when the alert is scoped to one operation.
Layout
Visually identical to service detail. Same eight panels, all scoped to the operation:
- ① HeaderOperation name (e.g.
POST /checkout), service name, the same coloured pill. - ② KPI stripRPS / p99 / error-rate / error-budget — for this one operation.
- ③ Four chartsRPS, latency, error rate, saturation — all narrowed to this operation.
- ④ Status code breakdownA stacked-area chart of HTTP status codes (2xx / 3xx / 4xx / 5xx) over time. Replaces the "saturation" tile when present.
- ⑤ Slow tracesThe 50 slowest traces for this operation in the window.
- ⑥ Error logsThe 50 most recent error-level logs whose
http.routematches this operation. - ⑦ Recent deploysDeploys to this service in the last 7 days.
- ⑧ Downstream callsA list of operations this operation called on other services, ranked by their contribution to total latency.
Why Operations exists as a separate screen
When you're triaging a service-wide alert, you usually find one operation is the problem. Pivoting from "the service is slow" to "POST /checkout is slow" is the most common drill. Having a screen that opens with the operation already focused — instead of you having to manually filter the service detail — saves clicks during high-stress moments.
When to use Operations vs Traces
- Operations — for aggregate questions: "is
POST /checkoutslower on average than yesterday?", "what's the error rate on this endpoint?". - Traces — for example questions: "show me one slow request and let me look at where its time went".
You'll often use both in sequence: Operations to confirm the pattern, then Traces to see an example.
The downstream-calls panel — read this carefully
Panel ⑧ is the closest thing Orbtrace has to a flame graph at the operation level. It lists every operation on every other service that this operation called, ranked by total contribution to latency over the window.
A row reads: inventory-service · GET /stock · 32% of total latency · p99 240 ms · 1,420 calls.
If the top row is "your own database call took 80% of the latency", you know where to look. The number is computed from spans, not from aggregate metrics — so it's only as good as your instrumentation. If a downstream service isn't sending OTel data, it shows as unknown-service and you've found a gap to plug.
Next: Admin pages.