Observability Features Overview

Overview

The platform's observability capabilities are a built-in feature, accessible from the same user interface used to manage API conversions. They are not a separate, licensed product. Every API call, configuration change, and backend test generates telemetry data, all of which is available for querying within the application and via the Admin API.

This system provides visibility across four main surfaces:

• Dashboards & KPIs: An operations dashboard with key performance indicator (KPI) tiles, timeline charts, and per-service data rollups.
• Metrics & SLO Reports: Aggregated metrics over fixed and custom time windows, along with Service Level Objective (SLO) reports that track availability and latency targets and detect breaches.
• Logs & Tracing: Structured runtime logs, a live traffic log with full request/response payloads and headers, contract-drift detection, asynchronous callback tracking, and debug traces.
• Audit Trail: A record of all configuration changes, detailing who changed what, when the change occurred, and the state before and after the change.

All observability data can be programmatically accessed through the Admin API endpoints under the /admin/v1/* path.

How It Works: Pre-Aggregated Metrics

The platform's core architectural principle for observability is to serve all time-bucketed metrics from pre-computed aggregation tables, rather than querying raw logs on demand. This design ensures consistent, high-performance metric queries, even with very large data volumes.

This pre-aggregation strategy provides two main benefits:

• Performance: Dashboards and reports load in sub-second time, even when displaying metrics for large estates over extended periods. For example, a reference estate of approximately 175 services can render 24-hour, 7-day, and 1-month per-service counts almost instantly because the queries read pre-calculated totals.
• Consistency: Because dashboards, SLO reports, and per-service timelines all query the same underlying aggregation tables, the numbers they display are always consistent with each other.

The diagram below illustrates the data flow for metric queries versus raw log access.

flowchart TD
    subgraph "Metric & Dashboard Queries"
        A[User query for dashboard or report] --> B{Pre-computed Aggregation Tables};
        B --> C[Fast, consistent response];
    end

    subgraph "Raw Log Access (Specific Use Cases)"
        D[Raw Telemetry Logs]

        D -- "Offline background process" --> E[Curator Workers];
        E -- "Writes aggregates" --> B;

        F[User drills down on a specific event] --> G{Query by Correlation ID};
        G --> D;
        D -- "Returns single raw log entry" --> H[Detailed Event View];

        I[Ingest Health Monitoring] --> J{Query for last event time};
        J --> D;
    end

Raw logs are reserved for three specific functions:

1. Ingest Health Signals: To monitor data pipeline health by checking for the last time a log was received from a specific source.
2. Specific Event Drill-down: To retrieve the full, detailed log entry for a single transaction when a user drills down from an aggregated view using a correlation ID.
3. Background Curation: To feed background workers that process raw logs offline to generate the pre-computed aggregation tables and other derived data.

Traffic Sources

All telemetry data includes a source dimension, which identifies the origin of the traffic. This allows you to filter metrics by a specific source or view them in aggregate. Default views sum data across all sources.

Correlation IDs

A single, unique correlation ID is attached to each request and travels with it through its entire lifecycle. This ID acts as a join key, linking the initial inbound call to any subsequent backend calls, mapping logic, structured logs, debug traces, and asynchronous callbacks.

When troubleshooting an issue, such as an error reported by an API consumer, you can use the correlation ID to search across all observability surfaces and retrieve the exact call, its full payloads, and its complete trace. For more information, see the documentation on correlation IDs in the API Reference.

Data Retention

By default, all telemetry and audit data is retained for 60 days. This retention window is configurable to align with your organization's data policies. For a detailed breakdown of retention periods for specific data tables, see the Data Retention policy documentation.

See Also

• Dashboards & KPIs
• Metrics & SLO reports
• Logs & tracing
• Audit trail
• Admin API — observability endpoints

All SOAP-to-REST docs