Loading…
Loading…
Monitor API health with dashboards for request volume, error rate, and latency. Drill down from estate-wide views to individual services and operations.
The operations dashboard provides a single, in-app view of the health of your entire API conversion estate. It is designed for engineers to monitor key performance indicators, diagnose incidents, and understand service behavior. The dashboard surfaces high-level metrics such as request volume, error rate, and latency, and allows you to drill down from an estate-wide perspective to a specific service and operation.
The primary design principle of the dashboard is performance. All displayed data is read from pre-computed aggregation tables, never from raw logs at query time. This ensures that all views, even across large estates and long time windows, load in sub-second time.
The dashboard's performance is achieved by adhering to a core architectural rule: all data is read from pre-computed aggregations, not raw logs. The platform continuously processes metrics in the background and stores them in optimized tables. When you load a dashboard, the UI queries these tables to render visualizations.
This approach avoids the performance penalty of scanning and aggregating large volumes of raw log data on-demand. The data flow is as follows:
GET /admin/v1/service-metric-timeline.GET /admin/v1/observability-filter-options.This ensures a responsive user experience for monitoring and incident investigation.
The dashboard is composed of several components that provide different views into the health of your services.
The top of the dashboard displays a row of Key Performance Indicator (KPI) tiles that provide an at-a-glance summary of the estate's health over the selected time window.
| KPI Tile | Description |
|---|---|
| Request volume | The total number of API calls processed. |
| Error rate | The percentage of calls that resulted in an error or fault. |
| Latency | The end-to-end latency for requests. Percentiles are available in drill-down views. |
| Rejection count | The number of requests rejected because their payload exceeded the 30 MB size limit. This is associated with error code S2R-RUN-0413. |
| Backend response mismatch | The count of contract-drift events detected. The tile also displays the reason for the most recent mismatch. |
| Bad-URL attempts | The number of runtime requests that omitted the required /{direction}/ segment in the URL path, triggering error S2R-RUN-0405. |
For correctly configured clients, the "Bad-URL attempts" count should be zero.
Timeline charts visualize traffic and error trends over the selected time window, which helps in identifying trends and pinpointing the start of an incident. Each service has a corresponding chart that plots the following metrics for each time bucket:
The time interval for the buckets is automatically adjusted based on the selected time window; shorter windows use finer-grained buckets, while longer windows use coarser ones. This data is provided by the GET /admin/v1/service-metric-timeline endpoint.
The dashboard allows you to drill down from the estate-wide view into a single service and further into a single operation. These detailed views provide more granular metrics:
413 Payload Too Large responses.A complementary master discovery view provides per-service request counts over 24-hour, 7-day, and 1-month periods, also served from aggregation tables for fast performance.
You can refine the data displayed on the dashboard using a set of filters and time window selectors.
The dashboard supports multi-select filters to narrow the scope of the data. The available filter options are dynamically loaded from the GET /admin/v1/observability-filter-options endpoint.
| Filter | Description |
|---|---|
environment | Filter by deployment environment. |
service | Filter by one or more services. |
operation | Filter by one or more operations within a service. |
source | Filter by traffic source, such as runtime or a specific connector like f5. By default, views aggregate data across all sources. |
You can select from several predefined time windows or specify a custom range.
15m, 1h, 24h, 7d, 30d, 60dFor more details on windowing, see the documentation on Metrics & SLO reports.
The dashboard UI is powered by the following Admin API endpoints. For complete details on these endpoints, refer to the Admin API reference.
| Endpoint | Method | Description |
|---|---|---|
/admin/v1/service-metric-timeline | GET | Serves aggregated time-series data for traffic and error trends. |
/admin/v1/observability-filter-options | GET | Provides the list of available options for the environment, service, and operation filters. |
The source does not specify the request or response schemas for these endpoints.
The dashboard KPIs highlight several specific error conditions.
| Condition | Trigger | Monitored By |
|---|---|---|
Payload Rejection (S2R-RUN-0413) | An inbound request payload exceeds the 30 MB maximum size limit. | Rejection count KPI |
Malformed URL (S2R-RUN-0405) | A client makes a request to a URL that is missing the /{direction}/ path segment. | Bad-URL attempts KPI |
| Contract Drift | A backend service returns a response that does not match the expected contract. | Backend response mismatch KPI |