Check Configuration

Overview

This page covers the configuration options that apply to all monitoring check types — intervals, thresholds, service linking, and failure behavior.

Check Types

Alert24 supports seven monitoring check types:

See HTTP Checks and Status Page Checks for detailed configuration guides.

Check Intervals

The check interval determines how frequently Alert24 runs your monitoring check. Available intervals depend on your plan.

Choosing an Interval

Shorter intervals detect problems faster but consume more resources. The free plan includes 10-minute intervals, which is sufficient for most monitoring needs. Paid plans unlock intervals down to 30 seconds for your most critical endpoints where rapid detection matters.

Real-Time Status vs. Historical Storage

Regardless of the check interval you choose, status page updates and alerts are triggered immediately when a failure is detected — your customers always see up-to-the-minute status.

However, check results are committed to the database at 5-minute intervals for historical storage. This means your uptime history charts and reports have 5-minute granularity, while live status remains real-time.

Check Locations

Alert24 runs checks from 15 global locations across 6 continents:

Default Behavior: Round-Robin

By default, every check automatically round-robins through all 11 locations. Each time a check runs, it runs from a different city. This gives you geographic diversity and distributes requests across different IP ranges — which prevents rate-limiting from monitored endpoints — without any configuration.

Selecting Specific Locations

You can also select specific cities to check from. When locations are explicitly selected, only those locations are used. This is useful when you want to monitor latency from specific regions your users are in.

Check Results

Each check result includes the city and region it was run from, so you can see per-location response times and identify region-specific issues.

Failure Thresholds

The failure threshold determines how many consecutive failures are required before Alert24 changes the service status and sends an alert.

Why Thresholds Exist

Not every failed check indicates a real problem. Network blips, temporary DNS issues, or server-side hiccups can cause a single check to fail without indicating an actual outage. Thresholds filter out this noise.

Threshold Options

• 1 consecutive failure — Alert immediately on the first failure. Use this for critical services where you'd rather get a false alarm than miss a real issue.
• 2 consecutive failures — A light filter that catches most transient issues.
• 3 consecutive failures — The recommended default. Reliably filters transient issues while still detecting real problems quickly.
• 5 consecutive failures — Conservative. Use this for services with known intermittent issues that aren't actionable.

Example

With a 10-minute interval (free plan) and a threshold of 3:

• Check fails at T+0, T+10m, T+20m
• Alert fires at T+20m (20 minutes after the first failure)
• If the check passes at T+10m, the failure counter resets — no alert

With a 60-second interval (paid plan) and a threshold of 3:

• Check fails at T+0, T+60s, T+120s
• Alert fires at T+120s (2 minutes after the first failure)

Service Linking

Every monitoring check should be linked to a service. This connection is what makes Alert24's automatic status updates work.

Linking During Check Creation

When creating a check, you'll select a service from the dropdown. You can also create a new service inline.

Linking After Creation

You can change the linked service at any time by editing the check configuration.

Multiple Checks Per Service

A single service can have multiple monitoring checks. For example:

• Production API service with:
  • HTTP check on /health (verifies the application is running)
  • HTTP check on /api/v1/users (verifies a real endpoint works)
  • SSL certificate check (verifies the certificate is valid)

When any check fails, the service status is updated. The most severe failure determines the status — if one check shows degraded performance and another shows a major outage, the service status will be Major Outage.

Alerting Behavior

When Alerts Fire

An alert is triggered when:

1. A check fails the configured number of consecutive times (failure threshold)
2. The linked service status changes

When Alerts Resolve

A resolution alert is sent when:

1. The check passes again after a failure
2. The linked service status returns to Operational

Notification Channels

Alerts are sent through your configured notification channels. You configure these at the organization level under Settings.

Pausing Checks

You can pause a monitoring check without deleting it. This is useful during:

• Planned maintenance windows
• Development or migration work
• Temporary service changes

Paused checks don't run, don't affect service status, and don't trigger alerts. Resume them when you're ready.

Editing and Deleting Checks

Editing

Open the check from the Monitoring page and click Edit. You can change any configuration option without recreating the check.

Deleting

Delete a check when you no longer need it. Deleting a check removes it from the service but doesn't change the service's current status.