Observability as a category on apis.io has more providers, more capability variation, and faster surface evolution than any other operational vertical. Five years ago it was a tools market. Today it’s a federation of telemetry types, and the catalog reflects the shift.
The four telemetry pillars and who plays where
The canonical observability data model is metrics, logs, traces, and events. The apis.io cohort partitions roughly along those lines, with each provider covering some subset:
| Pillar | Examples on apis.io |
|---|---|
| Metrics | Datadog, Grafana, Prometheus-as-a-Service, Chronosphere, M3 |
| Logs | Datadog Logs, Sumo Logic, Splunk, Elastic, Loki, Better Stack |
| Traces / APM | Datadog APM, Honeycomb, Lightstep (now ServiceNow), New Relic, Sentry, Tempo |
| Events / Incidents | PagerDuty, Opsgenie, Datadog Incidents, FireHydrant, incident.io, Rootly |
Most enterprise stacks combine three or four of these from different vendors, which is why the apis.io capability index is so much more useful than the provider list here. “Send a log line” is a capability across nine vendors. “Run a query against logs from the last 24 hours” is a capability across the same nine vendors, but with very different API shapes.
What’s actually moving
Three trends from the last six months in the observability cohort:
- OpenTelemetry is a quiet standardiser. Most of the modern providers in the catalog (Honeycomb, Grafana, Datadog, Sentry, New Relic) now publish OTLP endpoints alongside their native ingest APIs. This is the rare case where a category is converging on a shared API contract rather than diverging. The capability “ingest OTLP traces” appears in the catalog under multiple providers with nearly identical operations.
- Incident management is a category now. It used to be a feature of PagerDuty. Now incident.io, Rootly, FireHydrant, and Datadog Incidents all publish dedicated incident-API surfaces — separate from monitoring, separate from on-call. The catalog has an Incident Management category for exactly this reason.
- APIs for observability of AI workloads are emerging. LangSmith, Helicone, LangFuse, Arize, WhyLabs — these are new entrants whose entire purpose is to observe inference traffic. They’re appearing in the catalog as a distinct sub-category that didn’t exist 18 months ago.
What the federation looks like in practice
A modern stack might look like: traces in Honeycomb, logs in Better Stack, metrics in Grafana Cloud, incidents in incident.io, AI inference traces in LangSmith. Five providers, five APIs, one operational picture if you wire them together correctly.
That’s the integration cost the apis.io catalog is trying to compress. The provider pages tell you what each vendor exposes. The capability pages let you compare like-for-like across vendors. The category pages give you the cross-vendor shopping list for a given operational concern.
Where to start in the catalog
- Monitoring category — canonical filtered list.
- Incident Management category — the on-call / incident response cohort.
- Datadog and Grafana — the two most thoroughly profiled observability surfaces.
- Recent roundup posts: Observability Roundup, Incident Response Roundup.
The takeaway
Observability is the vertical where API portfolio breadth most directly predicts whether a vendor is operationally usable. The 85-API Datadog surface, the per-telemetry-type Grafana surface, the focused-but-deep Honeycomb surface — these are all expressions of the same federation. The capability layer in the catalog is what lets you compose them.
If your work touches operational data, walk the catalog by capability, not by provider. The picture that emerges is more useful than any single vendor’s docs sidebar.