How Checks Work
Understand check types, status changes, maintenance windows, and incident timing
A check is a scheduled monitor. MonitoringDog runs the check from selected locations, evaluates the configured condition, records results, and changes status only after the monitoring system confirms the change.
What a check monitors
Each check has one type. The type decides what MonitoringDog considers healthy.
| Type | Healthy when |
|---|---|
| 2XX HTTP status code | The target returns a 2xx HTTP response |
| Expected HTTP status code | The target returns one of the configured status codes |
| Keyword contains | The response succeeds and contains the required keyword |
| Keyword absent | The response succeeds and does not contain the blocked keyword |
Each check type targets an HTTP or HTTPS URL. Checks support a method, request headers, a request body, redirect handling, timeouts, basic HTTP authentication, and SSL expiry warnings for HTTPS.
Response time
Every check records how long each request took from each selected location and shows it on the check's response time chart. On the Business plan you can set a response-time threshold: a response slower than the threshold counts as a failure and opens an incident (slow-response alerts).
Status lifecycle
Checks move through a small set of statuses.
| Status | What it means | What happens next |
|---|---|---|
| Pending | MonitoringDog is waiting for the first scheduled result | The check becomes Up or Down after monitoring reports a result |
| Up | The configured condition is passing | Monitoring continues on the configured interval |
| Down | MonitoringDog confirmed the condition is failing | The related incident remains active until recovery is confirmed |
| Validating | MonitoringDog detected recovery and is waiting through the recovery period | The check returns to Up when recovery is confirmed |
| Paused | Active monitoring is stopped for the check | Monitoring resumes only after the check is resumed |
| Maintenance | The check is inside its maintenance window | Scheduled checks are skipped until the window ends |
Confirmation prevents noisy incidents
A single failed probe does not always open an incident. When an Up check receives a failing result, MonitoringDog starts a verification round across assigned workers.
If the workers confirm the target is down, MonitoringDog applies the Confirm Period:
| Confirm Period | Result |
|---|---|
| Immediate start | MonitoringDog can open the incident after the confirmed failure |
| A delayed period | The target must remain unhealthy through the period before MonitoringDog opens the incident |
This prevents short network blips from opening incidents when the check is configured to wait.
Recovery requires confirmed health
When a Down check receives a healthy result, MonitoringDog verifies recovery across workers and applies the Recover Period.
| Recover Period | Result |
|---|---|
| Immediate recovery | MonitoringDog can resolve the incident after confirmed recovery |
| A delayed period | The target must remain healthy through the period before MonitoringDog resolves the incident |
If the check fails again during the recovery period, MonitoringDog resets the recovery window and keeps the incident active.
Locations affect the monitoring signal
Checks run from selected locations. Each location reports independently, and MonitoringDog evaluates the combined result when deciding whether the check is up or down.
Use locations that match the users or systems you need to protect. For example, choose locations near your main customer regions when regional availability matters.
Maintenance pauses incident creation
Maintenance windows silence monitoring for planned work. During maintenance:
- MonitoringDog skips scheduled check dispatches.
- The check can show Maintenance.
- MonitoringDog does not open new incidents for skipped checks.
- After the window ends, the check returns to normal monitoring.
Configure maintenance days, start time, end time, and timezone together. A wrong timezone can make maintenance start or end at the wrong local time.
Pause and resume
Paused checks stop active monitoring until they are resumed. Pausing is useful when a target is intentionally offline outside a scheduled maintenance window.
Resuming a check can be blocked by the organization's check limit. If the organization is over the current plan limit, delete unused checks or update the plan before resuming paused checks.