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 network services where you need to verify availability from an external perspective.

Check Types

IonHour supports four outbound check types:

Type	What it does
HTTP	Sends an HTTP request and validates the response status code
TCP	Opens a TCP connection to a host and port
DNS	Performs a DNS lookup and verifies resolution
ICMP	Sends an ICMP ping to verify host reachability

HTTP is the most common type and supports the richest configuration.

Creating an Outbound Check

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

Setting	Description	Default
Name	Human-readable label	—
URL	The endpoint to probe (http:// or https://)	—
Interval	How often to probe	—
Check type	HTTP, TCP, DNS, or ICMP	HTTP

HTTP Configuration

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

Request Settings

Setting	Description	Default	Constraints
Method	HTTP method to use	GET	GET, HEAD, POST, PUT, PATCH
Custom headers	Additional HTTP headers to send	—	Max 10 headers
Timeout	How long to wait for a response	8,000 ms	1,000–15,000 ms
Follow redirects	Whether to follow HTTP redirects	Yes	—
Max redirects	Maximum redirect hops	3	0–3
Block HTTP downgrade	Prevent HTTPS to HTTP redirect downgrades	Yes	—

Response Validation

Setting	Description	Default
Expected status (min)	Minimum acceptable HTTP status code	200
Expected status (max)	Maximum acceptable HTTP status code	399

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.

Custom Headers

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

Certain headers are blocked for security:

• Host, Content-Length, Transfer-Encoding, Connection
• Cookie, Authorization
• X-Forwarded-*, Proxy-*

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.

Setting	Description	Default	Range
Fail after consecutive	Number of consecutive failures before marking DOWN	3	1–10
Resolve after consecutive	Number of consecutive successes before marking OK	2	1–10

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

Region ID	Location
us-east-1	US East (Virginia)
eu-west-1	EU West (Ireland)
ap-southeast-1	Asia Pacific (Singapore)

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.

SSL Certificate Monitoring

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

Setting	Description	Default
SSL expiry warning (days)	Alert when certificate expires within this many days	14

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.

Setting	Description	Default
Latency warning (ms)	Alert when response time exceeds this value	— (disabled)

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

Each probe follows this sequence:

1. DNS resolution — Resolve the target hostname. The resolved IP is validated to prevent SSRF attacks (internal/private IPs are blocked).
2. Connection — Open a TCP connection (2-second connect timeout).
3. TLS handshake — For HTTPS, negotiate TLS (3-second handshake timeout). Certificate details are captured.
4. Request — Send the HTTP request and read the response (up to the configured timeout).
5. Redirect following — If the response is a redirect and following is enabled, repeat from step 1 for the new URL. HTTPS-to-HTTP downgrades are blocked by default.
6. Validation — Compare the response status code against the expected range.

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:

Reason	What happened
DNS_ERROR	Hostname could not be resolved
CONNECT_TIMEOUT	TCP connection timed out
READ_TIMEOUT	Response not received within timeout
TLS_ERROR	TLS handshake failed
INVALID_CERT	SSL certificate is invalid
HTTP_4XX	Response was a 4xx client error
HTTP_5XX	Response was a 5xx server error
SSRF_BLOCKED	Target IP is private/internal (security protection)

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.