The Observability API provides a platform-wide view of operational health, delivery performance, and risk signals across all active Service Lines. It aggregates data from execution records, capacity allocations, usage metering, and product-line signals into a unified observability surface.This is not a metrics store you write to. Observability data is computed from the platform’s operational state. You query it to answer questions like:
Which Service Lines are at risk of SLA breach?
What is the delivery health score across this workspace?
Which teams have been consistently under-utilising allocated capacity?
Are there anomalies in agent execution that warrant investigation?
Every active Service Line has a health score (0-100) computed from a weighted set of signals. Scores are refreshed every 15 minutes. Scores below 70 are amber; scores below 50 are red.
# Delivery velocity over the quarterGET /v1/observability/metrics?workspace_id=WS-26-000021&metric=delivery_velocity&from=2026-01-01&to=2026-03-31&granularity=weekly# Capacity utilisation over the same periodGET /v1/observability/metrics?workspace_id=WS-26-000021&metric=capacity_utilisation&from=2026-01-01&to=2026-03-31&granularity=weekly
Automate the weekly health check. Schedule a webhook or polling job to run GET /v1/observability/risk every Monday morning. Route high severity risk factors to the right team via your integration.
Do not use observability as a substitute for real-time alerts. Observability scores are computed every 15 minutes. For real-time incident detection, use Incidents & Alerts.
Correlate observability signals with usage costs. Low utilisation on a capacity Service Line combined with high invoiced cost is a commercial issue, not just a delivery one.
Build trend views, not point-in-time views. A single health score tells you the current state. Weekly metric series tell you the direction. Direction matters more for stakeholder reporting.