Monitor Interfaces Before Disruptions Become Outages

Under RFC 9110, a 200 status means the request succeeded at the HTTP layer; the exact meaning depends on the method. It does not prove that a downstream business process finished. Google's SRE book describes an HTTP 200 response with incorrect content as an implicit error.

A health check is similarly limited to the condition it was designed to test. An application can appear healthy while work is stuck in a downstream queue.

OpenTelemetry describes metrics, traces, and logs among its signals; the current documentation also includes Baggage and Profiles. Metrics record and aggregate runtime measurements, a trace represents the path of a request, and logs record events. Those are typical roles rather than exclusive boundaries. A metric may narrow the relevant time window, a trace the affected path, and a log the reason for a rejection; correlation lets the views support one another.

Correlation and Error Contracts

That correlation requires consistent identifiers and comparable timestamps. W3C Trace Context standardizes traceparent and tracestate, and expressly prohibits using those fields for personally identifiable or other sensitive information. Even random identifiers can create privacy concerns when many requests are correlated. Access, retention, and deletion therefore remain architectural and governance decisions. Trace context also crosses trust boundaries. An external caller can supply it, so an internal service should not treat it as a privileged or inherently trustworthy origin marker. The architecture decides which fields to accept, regenerate, or remove. A trace ID can connect technical activity without placing customer, invoice, or case numbers in plaintext telemetry.

RFC 9457 defines Problem Details as a machine-readable format for HTTP errors. A problem type, HTTP status, and instance reference can provide a stable error contract.

The format is not intended for stack traces, internal paths, or confidential implementation details. Internal diagnostic records may contain more information but need a reliable way to correlate with the external occurrence. For machine processing of Problem Details, RFC 9457 distinguishes the stable problem type in type from the specific occurrence in instance. The text in title and detail is intended for people. A client should therefore avoid making its error handling depend on descriptive wording that may change through translation. This separation supports understandable messages without changing the machine-readable contract whenever the wording is corrected.

Requests Missing from the Traces

Tracing may use sampling. With head sampling, selection happens early, before the full request path is known. An error that occurs later may therefore belong to a request whose trace is not retained.

Tail sampling decides after observing more of the path and can use errors or high latency as selection criteria. That approach requires state and controlled memory use. It does not guarantee completeness either. For an investigation into a missing order, this creates a limit: a missing trace does not prove that the call never occurred. The sampling policy and possible collection or transport losses belong in the diagnosis. If the process requires a complete business record, that record must be maintained independently of telemetry that may have been sampled. This recommendation follows from the sampling limits described by OpenTelemetry; it does not prescribe a particular storage architecture.

Alerting

Google SRE distinguishes the user-visible symptom from evidence about its cause. On-call staff first need to know what service has shown what effect and since when. Low resource use does not mean the system is healthy if transactions are incomplete. If an alert always triggers the same prescribed response, the team should consider automating that response instead of waking the on-call engineer.

Thresholds also need a denominator. A fixed error count can mislead when daily volume changes sharply, while a percentage says little at very low volume.

A locally defined alert record can capture the observed value, its denominator, and a first response. The cause does not have to be proven at that point. Start time, scope, versions, and visible business transactions help with triage; Google does not prescribe that exact field list as a standard.

Where a service level objective has been agreed, alerting can also account for error-budget consumption. The burn rate describes how quickly that budget is being spent relative to the allowable rate. The Google SRE Workbook combines longer and shorter observation windows: the longer window captures sustained consumption, while the shorter one indicates whether the disruption is still present. Its values are examples, not universal thresholds for a B2B interface.

Interpretation needs particular care at low transaction volumes. A single failed call can produce a high error rate. Synthetic requests can provide additional signals, but they cover only the cases designed into them. Combining them indiscriminately with real user requests can allow many successful probes to obscure real failures in the aggregate. These populations must remain distinguishable for operating decisions.

Inventory and Retirement

OWASP identifies incomplete API inventories and missing retirement plans as a risk. The inventory should capture environment, version, intended network access (such as public, internal, or partner access), and sensitive data flows. Declaring an endpoint retired does not make it unreachable; older controls or unpatched components can remain exposed while callers or access paths still exist. As an operating extension, the inventory can also link each endpoint to expected signals and an accountable team. Changes should preserve the trace and error contract or document the difference. As a local retirement rule, callers should migrate, access should be revoked, and the old route should be verified as unreachable. For an operations handoff, a reproducible test, the location of raw signals, and the next diagnostic step provide stronger evidence than a single dashboard screenshot.

Note: This assessment is not a substitute for a review of the specific case.