Transport Errors, Timeouts, and IPv4 Fallback

Last updated: 2026-03-06

Some monitors fail because the service is truly down. Others fail because of network path issues between a check region and your endpoint (for example, IPv6 path instability while IPv4 is healthy).

This guide explains how StatusPage handles those cases and why you may see an UP result with an IPv4 fallback note.

What Changed

For HTTP/API monitors, checks now use:

1. Interval-aware timeout instead of a fixed 10-second timeout
2. One retry over IPv4 for eligible transport failures (GET/HEAD only)
3. Explicit metadata + UI note when fallback succeeds

If the first request fails but the IPv4 retry succeeds, the check is saved as UP and shown with a note like IPv4 fallback.

Timeout Behavior

Timeout is calculated from monitor interval:

• Minimum timeout: 10s
• Maximum timeout: 30s
• Guardrail: timeout stays about 2s below interval where possible

Examples:

• 30s interval monitor -> ~28s timeout
• 60s interval monitor -> 30s timeout cap

This reduces false DOWN events from slow responses while avoiding timeout values that equal the full interval.

When IPv4 Fallback Runs

Fallback is intentionally conservative:

• Initial request uses normal network selection (IPv4/IPv6 auto)
• If it fails with an eligible transport class, one retry is attempted over IPv4
• Retry is only used for GET and HEAD requests (safe/idempotent)

Typical eligible transport failures include:

• timeout
• connection reset by peer
• connection refused
• TLS handshake timeout
• EOF / unexpected EOF
• HTTP/2 GOAWAY

DNS errors such as no such host, expected-condition mismatches, or HTTP 404/500 responses are not reclassified as fallback success.

Why You Might See “UP (IPv4 fallback)”

This usually means:

• IPv6 route/edge path from the checker had a transient failure
• IPv4 route worked immediately on retry
• Your service was still reachable for many users

Operationally, this is treated as UP with a network note, not a confirmed outage.

Where To See It

In the Monitors page under Recent Checks, each row can show:

• status (UP / DOWN)
• response time
• age
• optional fallback note (IPv4 fallback)

That note indicates successful recovery on IPv4 after the first transport error.

Support Troubleshooting Playbook

If a customer reports repeated fallback notes:

1. Compare IPv6 and IPv4 from the same region environment (curl -6 vs curl -4)
2. Check CDN/WAF/firewall behavior for IPv6 listener parity
3. Confirm origin and edge certificates are valid on both families
4. Review monitor expected conditions separately from transport reliability

If fallback notes are frequent, treat it as an infrastructure signal: uptime may look good, but IPv6 user experience may still be degraded.

Related Docs

• Choosing Monitor Locations
• Setting Your Primary Monitoring Region
• Monitoring Accuracy & Detection Tracking
• Monitoring Types