Reproducible technical scenario
The API returned 200. Background work was still failing.
A green endpoint proves that one request path answered, not that billing, exports, imports, or scheduled work produced the right result. This automated lab scenario keeps those component truths separate while making the overall outage visible.
Last reviewed: August 1, 2026
Test-backed lab scenario
This is not an observed customer incident. Automated acceptance coverage combines successful uptime evidence and failed background-output evidence on one status page; it does not establish production scale or measured user impact.
Direct answer
One healthy component cannot overwrite an active background incident.
The uptime monitor expects HTTP 200 and records a successful probe. Its linked API component remains operational.
A separate background monitor completes with a numeric output that fails its configured condition. That run becomes failed, an invalid_output incident opens, and the background component becomes a major outage.
The shared public page becomes a major outage because an active component incident takes precedence. It still preserves the API component as operational, so operators and visitors can see exactly which part is healthy and which part is not.
Verified component state
A truthful page can show green and red at the same time.
- Public API Operational
- The probe received the configured 200 response. The scenario does not rewrite or downgrade that valid uptime evidence.
- Background invoice processing Major outage
- The process reported nominal success with output below its required threshold. The active invalid-output occurrence governs this component.
What this proves
- A successful HTTP probe remains visible as valid evidence for its own component.
- A separate failed background outcome opens its own incident and component outage.
- The overall page follows the active incident rather than the healthiest component.
- Visitors can see the affected component without being told the entire API is down.
- A later valid background completion can recover the affected occurrence.
Current boundary
- The scenario is automated product proof, not a customer case study or production benchmark.
- Teams must configure and link separate monitors for the service components they want represented.
- An HTTP 200 check does not validate database state, queue progress, or business output by itself.
- LatidoFlow detects and communicates the configured failure; it does not automatically repair the job.
- Status updates are visible on the page. Subscriber email delivery is not implemented.
Build a component-aware monitoring model
Model the work behind the endpoint.
Keep your API probe, then add evidence for the background process whose failure would make a green endpoint incomplete.