Every health check is green. Why can't users complete the journey?

01 · SCENARIO · Intermediate

Fictional educational scenario. A portal accepts applications. Its web service, API, database and message broker pass health checks, and the infrastructure dashboard reports 99.99% uptime. The /health endpoint responds 200, while application creation returns an identifier.

But confirmations have stopped appearing in the portal. An event consumer has stalled on a deserialization error, messages are accumulating and applications remain 'processing'. Operations suggests calling the service available because the infrastructure is healthy, and scaling up the API. The agreed completion time is not yet known, nor is it clear whether queued events can safely be retried.

Your question

Would you classify the service as available? In 2–3 sentences state its boundary, the signals and controlled test you need, and what would change your decision.

Guiding questions

Does HTTP 200 from /health prove completion of the user journey?
Which asynchronous stage stopped making progress?
How can you tell expected delay from a permanently stuck queue?
How do you resume without repeating a business outcome?

Compare your reasoning

Read the full analysis at any time, including without AI feedback.

A green component is not a completed journey

Do not infer the health of the entire business journey from component health checks. The API may accept a request while downstream asynchronous processing is stalled. If the contract promises acceptance only, distinguish acceptance availability from processing timeliness; do not invent an immediate-completion promise.

Three approaches

A — Infrastructure uptime alone: simple to run, but blind to a stuck business process.
B — Only an end-to-end production probe: catches integration failures but can create real business effects, test data and misleading alerts without isolation and cleanup.
C — Layered signals and a safe synthetic journey: retain liveness/readiness, add age of oldest outstanding work, completion rate and the share of applications reaching the agreed final state within its agreed time window; run an isolated end-to-end probe. Choose C here, once the meaning of 'complete' and the acceptable duration are agreed.

Evidence to collect

Separate acceptance from completion: define start and end states, measurement points and UI behaviour during processing delay.
Measure progress, not only queue depth: capture oldest pending age, processing rate, permanent failures and dead-letter flow. Queue size alone varies with traffic.
Define user-facing SLI and SLO: for example the proportion of accepted applications reaching the final state within an agreed window, without inventing a numerical threshold.
Use a safe probe: a dedicated identity and non-impacting test data, bounded frequency and reliable cleanup; verify the final state and the absence of duplicate results.

Decision gate

Stop the consumer deliberately in a controlled test. The API may still accept requests, but a process-progress alert must identify the failure within the agreed window. Resume processing and verify reconciliation without duplicates. A prolonged failure may require limiting new submissions or showing a user notice, depending on queue capacity and the actual service contract.

Service availability is a claim about a promised outcome, not merely about processes returning HTTP 200.

Every health check is green. Why can't users complete the journey?

What would you do?

Revise your answer

Compare your reasoning

A green component is not a completed journey

Three approaches

Evidence to collect

Decision gate

Understand the principle and its limits