Loading…
Loading…
Query aggregated API metrics and generate SLO reports for availability and latency. Learn about the available metrics, filters, and SLO targets.
The platform provides aggregated metrics and Service-Level Objective (SLO) reports through dedicated API endpoints. These tools allow API publishers to monitor service health, performance, and adherence to defined service levels.
All queries for metrics and SLOs are served from pre-computed aggregation tables, not from raw logs at query time. This design ensures that requests for data over long time periods or across a large number of services return quickly. The default data retention for these aggregations is 60 days.
This document details the two primary endpoints for this data: /admin/v1/metrics for aggregated performance metrics and /admin/v1/slo-report for generating reports against availability and latency targets.
The system continuously processes API traffic data, aggregating it into optimized tables. When an API consumer requests metrics or an SLO report, the platform queries these pre-computed tables to generate the response. This avoids the performance cost of processing raw event logs on-demand.
The data flow is as follows:
flowchart TD
subgraph Platform
A[API Traffic] --> B{Aggregation Process};
B --> C[(Pre-computed Aggregation Tables)];
end
subgraph "API Endpoints"
C --> D["/admin/v1/metrics"];
C --> E["/admin/v1/slo-report"];
end
F[API Consumer] --> D;
F[API Consumer] --> E;All time-series endpoints, including metrics and SLO reports, use a common vocabulary for specifying the query window. You can use a fixed time window or a custom range.
The following fixed window values are supported:
15m 1h 24h 7d 30d 60d
To query a specific period, you can provide start and end parameters with ISO-formatted timestamps. The custom range must be within the platform's data retention horizon, which is 60 days by default.
NOTE
The 60-day retention period is a configurable default. For more details, see the platform's data retention documentation.
The Metrics API provides aggregated performance data grouped by environment, service, and operation.
GET /admin/v1/metrics
The response contains an array of objects, each with the following metrics calculated over the specified time window.
| Metric | Type | Description |
|---|---|---|
requestCount | Number | The total number of requests in the window. |
errorCount | Number | The number of requests that resulted in an error or fault. |
p50LatencyMs | Number | The 50th percentile (median) end-to-end latency in milliseconds. |
p95LatencyMs | Number | The 95th percentile end-to-end latency in milliseconds. |
p99LatencyMs | Number | The 99th percentile end-to-end latency in milliseconds. |
p95ConverterOverheadMs | Number | The 95th percentile of overhead latency introduced by the conversion layer. This is calculated as max(0, latencyMs − backendLatencyMs). If backend latency is not available, this value falls back to total latency. |
Use these parameters to filter the metrics data.
| Parameter | Type | Default | Required | Description |
|---|---|---|---|---|
window | String | — | No | A fixed time window. One of 15m, 1h, 24h, 7d, 30d, 60d. Use either window or start/end. |
start | String | — | No | The start of a custom time window as an ISO timestamp. Must be within the 60-day retention period. |
end | String | — | No | The end of a custom time window as an ISO timestamp. |
environment | String | — | No | Filters results to one or more environments. This parameter can be repeated to select multiple values. |
serviceKey | String | — | No | Filters results to one or more services. This parameter can be repeated to select multiple values. |
The SLO Report API generates a service-level report that measures measured performance against user-defined targets for availability and latency.
GET /admin/v1/slo-report
You can specify the following targets as query parameters. If omitted, the documented defaults are used.
| Parameter | Type | Default | Required | Description |
|---|---|---|---|---|
availabilityTarget | Number | 99.5 | No | The target availability percentage (e.g., 99.9). |
p95LatencyTargetMs | Number | 500 | No | The target 95th percentile latency ceiling in milliseconds. |
The report response contains the following fields, comparing measured performance to the specified targets.
| Field | Type | Description |
|---|---|---|
availabilityPct | Number | The measured availability percentage over the entire window. |
availabilityTarget | Number | The availability target used for the report. |
p95LatencyMs | Number | The measured 95th percentile latency over the entire window. |
p95LatencyTargetMs | Number | The p95 latency target used for the report. |
availabilityBreach | Boolean | true if availabilityPct is less than availabilityTarget. |
p95LatencyBreach | Boolean | true if p95LatencyMs is greater than p95LatencyTargetMs. |
breach | Boolean | true if either availabilityBreach or p95LatencyBreach is true. |
breachBucketCount | Number | The number of individual time buckets within the window that breached at least one target. |
timeline[] | Array | An array of objects representing discrete time buckets within the window. Each object contains its own metrics and breach flags, allowing you to identify when breaches occurred. |
In addition to the SLO target parameters, you can filter reports using the following:
| Parameter | Type | Default | Required | Description |
|---|---|---|---|---|
serviceKey | String | — | Yes | The service to generate the report for. The source does not specify if this is repeatable. |
window | String | — | No | A fixed time window. Use either window or start/end. |
start | String | — | No | The start of a custom time window as an ISO timestamp. |
end | String | — | No | The end of a custom time window as an ISO timestamp. |
Because the report includes breachBucketCount and the timeline[] array, it is possible to distinguish between a brief, transient issue and a sustained outage. Both events will lower the overall availabilityPct, but a sustained outage will result in a higher breachBucketCount and more consecutive breached buckets in the timeline.