HTTP & Outbound Checks

Outbound checks work the opposite way from cron monitoring. Instead of your service pinging Ionhour, Ionhour actively probes your endpoints on a schedule and verifies they're responding correctly.

This is ideal for monitoring websites, APIs, and public services where you need to verify availability from an external perspective.

Creating an Outbound Check

When creating a check, set the check mode to Outbound. At minimum, you need:

HTTP Configuration

HTTP checks give you fine-grained control over the request and what constitutes a successful response.

Request Settings

Response Validation

Any response status outside this range is treated as a failure. For example, the default range of 200–399 accepts all 2xx and 3xx responses as healthy.

Body Assertions

You can optionally validate the response body content:

Body assertions are useful for verifying that your endpoint is returning the expected content — not just a 200 status code. For example, you can check that a health endpoint returns "status":"ok" rather than an error page that happens to return HTTP 200.

Both fields are optional and can be used independently or together.

Custom Headers

You can send custom headers with each probe request — useful for passing API keys, health check tokens, or custom identifiers.

Failure and Recovery Thresholds

Outbound checks don't create incidents on the first failure. Instead, they use consecutive failure/success counters to avoid alerting on transient issues.

With the defaults:

• A check must fail 3 times in a row before an incident is created.
• After going down, it must succeed 2 times in a row before the incident is resolved.

This prevents noisy alerts from single-request timeouts or brief network blips.

Multi-Region Probing

Ionhour probes your endpoints from multiple geographic regions to detect regional outages and provide a global view of availability.

Available Regions

If no regions are specified, probes run from us-east-1 by default.

When multiple regions are configured, each region runs its own independent probe on the same schedule. This means you get separate latency data and failure tracking per region.

Multi-Region Consensus

When a check uses multiple regions, Ionhour doesn't rely on a single region's opinion. Instead, it uses a consensus algorithm that evaluates all regions together before changing the check's status.

To go DOWN: A majority of active regions must have consecutive failures at or above the failure threshold. Majority is calculated as ceil(N/2) where N is the number of active regions.

To recover (OK): All active regions must have consecutive successes at or above the recovery threshold. This is intentionally asymmetric — going down is fast (protects against outages), while recovery is conservative (prevents premature resolution).

Example (3 Regions, Fail Threshold = 3, Resolve Threshold = 2)

Staleness Filtering

Regions that haven't reported a probe result within 2x the check's interval are considered stale and excluded from consensus. This prevents an unresponsive probe region from blocking status transitions.

For example, if your check runs every 60 seconds, a region that hasn't reported in the last 120 seconds is excluded from the vote.

Minimum Quorum

If a multi-region check has fewer than 2 active (non-stale) regions, Ionhour enters degraded mode — no consensus is reached and the check stays in its current state. This prevents a single remaining region from unilaterally changing the check's status.

SSL Certificate Monitoring

For HTTPS endpoints, Ionhour automatically tracks SSL certificate expiry alongside health checks.

When the certificate on your endpoint is within the warning threshold, Ionhour sends an SSL Expiring alert. This is separate from the health check — your endpoint can be healthy but still trigger an SSL warning.

Latency Monitoring

Set a latency threshold to get alerted when response times exceed acceptable limits.

Latency alerts have a 1-hour cooldown per check to avoid alert fatigue. If your endpoint is consistently slow, you'll get one alert per hour rather than one per probe.

How Probes Execute

If a probe fails, Ionhour retries once with a 300ms delay before recording a failure. Certain transient errors (502, 503, 504 responses and temporary DNS failures) trigger an additional retry.

Error Categories

When a probe fails, the reason is categorized:

Outbound Statistics

Ionhour tracks aggregated statistics for outbound checks:

• Uptime percentage — Ratio of successful probes over a time window.
• Average latency — Mean response time across probes.
• P95 latency — 95th percentile response time.
• Timeline — Bucketed probe results over time (default: 5-minute buckets over 24 hours).

These are available in the check detail view and via the API.

Best Practices

• Start with defaults. The default thresholds (3 consecutive failures, 2 consecutive recoveries) work well for most services. Tighten them only after you've baselined your endpoint's behavior.
• Use multiple regions for production services. A single-region check can't distinguish between your service being down and a network issue between the probe and your service.
• Set realistic timeouts. If your API normally responds in 500ms, a 2-second timeout is reasonable. Don't set it to 15 seconds unless you expect slow responses.
• Monitor SSL expiry even if you have auto-renewal. Let-encrypt renewals can fail silently. A 14-day warning gives you time to fix it.
• Use the expected status range to match your endpoint's behavior. A health check endpoint that returns 204 on success needs a range of 200–204, not the default 200–399.
• Don't monitor internal services from outbound checks. They're designed for externally-reachable endpoints. Use cron monitoring with an internal health check script instead.