Skip to content

Retries and verification

Why one failed request does not open an incident, and how verification confirms a real failure.

Core

Fajita separates two questions so alerts stay trustworthy.

StepAnswers
Check retryWas this one failed request temporary?
Incident verificationIs the service meaningfully unhealthy?

The sequence

Failed checkRetryStill failing?Count consecutive failuresThreshold met opens incident

A scheduled check fails. Fajita retries the request. If the retry also fails, the failing result becomes eligible for verification. Verification counts consecutive eligible failures against the monitor's failure confirmation threshold. When the threshold is met, an incident opens. If a check passes before the threshold, the monitor returns to operational.

Retry decides transience, verification decides health

Verification threshold

Each monitor has a failure confirmation threshold, defaulting to two consecutive eligible failures. Critical monitors can open faster. A single failing check never opens an incident on a normal monitor.

Why this matters

  • A retry result stays in history so you can see what happened.
  • Manual tests do not open incidents.
  • Platform uncertainty (a problem on Fajita's side) does not automatically blame your service.

Was this page helpful?