Retries Before Alerting
What are retries?
Section titled “What are retries?”Retries re-attempt a failing check before we send you an alert. A single failed request is not always a real outage: a brief network blip, a slow cold start, or a one-off timeout can all fail a check while your API is healthy. Retries let you confirm a failure is real before anyone gets paged.
Retries only happen when a check fails. A passing check never retries, so the setting costs you nothing while everything is healthy.
Retries are available for API, multistep, TCP and DNS checks. Browser checks do not retry; they alert after N consecutive failures instead, as described below.
Why use retries?
Section titled “Why use retries?”The main reason is alert noise. Without retries, every transient blip becomes an alert, and alerts that are usually false get ignored. With retries, you only hear about failures that survived several attempts.
New checks start with 2 retries, which filters transient blips without delaying a real alert much. Set Retries to 0 to turn the feature off. Existing checks keep whatever they were saved with.
The settings
Section titled “The settings”The settings are in the Retries before alerting section of the check form on the New API Check page.
| Setting | Range | Default | What it does |
|---|---|---|---|
| Retries | 0 to 5 | 2 | How many extra attempts to make after the first failure |
| Interval (s) | 1 to 60 | 10 | The base wait between attempts |
| Backoff | Fixed, Linear, Exponential | Fixed | How the wait grows with each attempt |
| Max retry time (s) | 1 to 300 | 60 | A total time budget for the whole retry sequence |
A retry always runs from the same location as the failed attempt.
How backoff works
Section titled “How backoff works”Backoff decides how long we wait before each retry, starting from your Interval. For an interval of 10 seconds:
| Attempt | Fixed | Linear | Exponential |
|---|---|---|---|
| 1st retry | 10s | 10s | 10s |
| 2nd retry | 10s | 20s | 20s |
| 3rd retry | 10s | 30s | 40s |
- Fixed waits the same interval every time. Use it when you expect a failure to clear quickly.
- Linear grows the wait steadily. A reasonable middle ground.
- Exponential doubles the wait each time. Use it when a struggling service needs room to recover, and you do not want your retries adding to the load.
Max retry time
Section titled “Max retry time”Max retry time is a budget for the whole sequence, measured from the start of the first attempt. Before each wait, we check whether that wait would push the sequence past the budget. If it would, we stop and report the last failure.
This means the budget can end your retries before you have used all of them, which is intentional. For example, with an interval of 10 seconds, Exponential backoff, 3 retries, and a 60 second budget, the third retry would need a 40 second wait on top of roughly 30 seconds already spent. That exceeds the budget, so the check stops after the second retry.
If you want all your retries to run, make sure the budget is larger than the total of the waits above.
What gets recorded
Section titled “What gets recorded”Only the final attempt is saved as the check's result. This is what makes retries useful:
- Fails, then passes on a retry: the check is recorded as passing and no alert is sent. The blip never reaches you.
- Fails every attempt: the check is recorded as failing and your alert channels fire as usual.
Because only the final result is stored, retries do not distort your uptime figures with transient blips.
Browser checks: alert after N consecutive failures
Section titled “Browser checks: alert after N consecutive failures”Browser checks do not retry. In the same section the field becomes Alert after N consecutive failures, and your check frequency is the spacing between runs. LoadFocus alerts when N failed runs happen in a row, from 0 to 5. A value of 0 or 1 alerts on the first failed run.
A recovery notification is only sent when an alert was sent, so a short blip that never reached N does not produce a "recovered" message.
Alert on every failure
Section titled “Alert on every failure”Under Advanced notification options, the toggle every time a check fails sends an alert for each failing run instead of only when the check starts failing. For a browser check with N above 1, it starts alerting once N failed runs in a row are reached and then alerts on every further failed run. keep reminding me while a check stays down sends repeat reminders on a schedule you choose.
Alert only when several locations fail
Section titled “Alert only when several locations fail”By default, one failing location marks the whole run as failed. A check defined in a YAML file with Monitoring as Code can set locationFailureThreshold to a number N above 1: it then alerts only when at least N locations fail the same run.
Practical use cases
Section titled “Practical use cases”- Public APIs over the internet: 1 to 2 retries with Fixed backoff and a short interval filters out routine network noise.
- Services that cold start: use Linear or Exponential backoff so a slow first response has time to warm up.
- A service under load: use Exponential backoff so your retries give it room instead of adding pressure.
- Critical checks that must page immediately: set Retries to
0so a single failure alerts straight away.
A note on frequency
Section titled “A note on frequency”Keep your retry budget below your check frequency. If a check runs every minute and its retries can keep going for longer than a minute, a failing check would still be retrying when its next run is due.
Related guides
Section titled “Related guides”- How to Create a New API Check for the shared check settings
- Alert Channels to choose where alerts are delivered
- Uptime Monitoring