EDI metrics: SLO, error budgets, KPIs

A modern EDI hub cannot be run "by eye". Instrumentation — metrics, traces, logs — and the explicit definition of Service Level Objectives are the foundations of large-scale operations. This page lays out the conceptual frame and the key indicators.

Why measure an EDI

An EDI system is a distributed system: dozens of partners, several protocols, several formats, and asynchronous flows that can last hours or even days. Without measurement: incidents are discovered by partners who phone in, silent regressions (an error rate climbing from 1% to 5%) go unnoticed, capacity/cost trade-offs are made "by gut".

Benefits of rigorous instrumentation:

• Early detection of degradations before the partner notices.
• Faster diagnosis via distributed traces and correlated logs.
• Budget arbitration: deciding where to invest (capacity, reliability, new feature) with data.
• Contractual compliance: proving partner SLA adherence.
• Roadmap steering: translating a business objective into a measurable technical target.

SLO, SLI, SLA, error budget

The SRE vocabulary rigorously distinguishes:

• SLI (Service Level Indicator): an objective measurement of an aspect of the service (AS2 send p95 latency, 24h error rate).
• SLO (Service Level Objective): a target set on an SLI (e.g.: 99.5% of AS2 sends under 5 seconds over 30 rolling days).
• SLA (Service Level Agreement): the contractual commitment to a partner or customer, usually looser than the internal SLO, and tied to penalties.
• Error budget: the margin tolerated by the SLO. For a 99.5% SLO, the error budget is 0.5% — about 3.6 hours of unavailability per month. Once consumed, deployments are frozen and sprints are devoted to reliability.

The SLO / error budget pairing is the tool that turns reliability into a tangible, arbitrable metric, rather than a vague injunction ("be reliable").

Latency: p50, p95, p99

EDI flow latency is measured at several levels:

• Ingest latency: time between AS2/AS4 reception and MDN/receipt returned. Typical target: p95 < 5s.
• Internal pipeline latency: time between ingest and publication on the canonical event store. Typical target: p95 < 30s.
• End-to-end latency: time between ingest and destination ERP ack. Typical target: p95 < 5 min (varies by flow).
• Partner latency: time between emission and partner ack reception. Contractual partner SLA.

Percentiles (p50, p95, p99) are indispensable: the average hides tails. A system with acceptable p95 but catastrophic p99 is unstable. Hidalgo (op. cit.) recommends building SLOs on p95 or p99 rather than on average, and aligning with real user expectations.

Success and error rate

Success rate is the other pillar of EDI SLOs:

• Syntactic acceptance rate: % of received messages that pass the parser (positive CONTRL).
• Semantic acceptance rate: % that pass business rules (EN 16931 validators, Schematron).
• Business acceptance rate: % that pass customer rules (credit limits, authorisations).
• Partner ack rate: % of sent messages that received their MDN/receipt.

Each rate is measured on a rolling window (24h, 7d, 30d) and broken down by partner and message type. Acceptable thresholds depend on context — 99.9% for tax invoices, 95% for less critical flows.

Dropped messages and DLC

A message landing in a Dead Letter Channel is a dropped message. The DLC rate is a key indicator of system health. Typical targets: < 0.1% in steady state, alert if > 0.5%. Drop causes:

• Parsing error (unexpected format, unknown encoding).
• Semantic validation error (missing mandatory field).
• Routing error (unknown partner).
• Enrichment error (unresolved reference).
• Definitive send failure (retries exhausted).

The DLC dashboard must show distribution by cause, by partner and by message type — without this, symptoms are treated instead of root causes.

MDN / Receipt time-to-ack

For AS2, the MDN (Message Disposition Notification) is the cryptographic reception receipt. The time between message emission and signed MDN reception is the MDN time-to-ack. For AS4, the equivalent is the ebMS receipt. Typical target: p95 < 30s in synchronous mode, < 5 min in asynchronous mode.

A non-arriving MDN (timeout) is a major event: retransmission must follow the Retry with backoff pattern, never assume the partner received without proof, and open a non-repudiation ticket if the retry threshold is reached.

OTIF per partner

OTIF (On Time In Full) is the historical supply-chain indicator: % of orders delivered on time and complete. Applied to EDI:

• On Time: % of messages sent within the contractual window (typically ≤ 24h after order).
• In Full: % of complete messages accepted at first try.

Measured per partner, EDI OTIF allows investment arbitration: a partner whose OTIF has drifted for 3 months deserves specific analysis (spec change, volume ramp-up, partner degradation itself).

2026 observability stack

The modern stack relies on OpenTelemetry (CNCF, 2019) as the instrumentation standard, and several backends:

• Metrics: Prometheus, Grafana Mimir, Datadog, New Relic, Splunk Observability Cloud.
• Traces: Jaeger, Tempo, Datadog APM, Honeycomb.
• Logs: Loki, Elasticsearch, Datadog Logs, Splunk.
• Dashboards: Grafana dominates, with managed SaaS offerings (Grafana Cloud, Datadog).

The major investment is less in backend choice than in instrumentation discipline: each service publishes its metrics and traces with consistent tags, the traceId is propagated end to end, logs are structured (JSON) and correlated to the traceId.

Further reading

• Modern integration architecture — where to instrument in the pipeline.
• ISGo architecture 2026 — multi-tenant observability in practice.
• Wire Tap and Message History patterns — the technical brick under instrumentation.
• Correlation Identifier — without it, no reliable distributed tracing.