Uptime Monitoring

Uptime monitoring is the most fundamental check in Hoppla. It makes HTTP or HTTPS requests to your URL and verifies that the response meets your expectations -- correct status code, acceptable response time, and optionally the presence or absence of specific keywords in the response body.

How It Works

On each check cycle, Hoppla sends an HTTP request to your monitor's URL from its primary probe location. It records the response status code and response time, and (when configured) checks the response headers and body against your rules.

Dual-Check Verification

To eliminate false positives caused by transient network issues, Hoppla uses dual-check verification. When an uptime check fails from the primary probe location, a second check is automatically dispatched from a different geographic location. An incident is only created if the check fails from both locations.

This means you will never be woken up at 3 AM because of a brief routing blip between Hoppla's primary probe and your server.

Connectivity Canary

Hoppla also runs a connectivity canary -- a lightweight check against a known-good endpoint. If the canary fails at the same time as your check, Hoppla assumes the problem is on its own network and marks your check as ok rather than raising a false alarm.

Configuration

Setting	Default	Description
Expected status code	Any 2xx/3xx	The HTTP status code your URL should return. Set this to 200 if you want strict matching, or leave it unset to accept any successful response (200-399).
HTTP method	GET	The HTTP method to use. Supports GET, POST, PUT, and HEAD.
Timeout	10s	Maximum time to wait for a response, in seconds (1-60).
Slow response threshold	Off	A response that is correct but takes at least this many milliseconds (1-60000) counts as slow: the check shows a warning instead of OK and still counts as up. By default, two slow results in a row send warning.slow_response. Leave it empty and response time never raises a warning. Set it when you create the monitor or later under the check's settings.
Check interval	60s	How often to run the check (30s to 24h).
Follow redirects	Yes	Whether to follow HTTP redirects automatically.
Max redirects	5	Maximum number of redirects to follow (capped at 20).
Expected final URL	(none)	If set, the check fails unless the request lands on this exact URL after following redirects. Trailing slashes are ignored.
Verify SSL	Yes	Whether to verify the SSL certificate during the request.
Keyword present	(none)	A string that must appear in the response body. If the keyword is not found, the check fails. Case-insensitive. Max 500 characters.
Keyword absent	(none)	A string that must NOT appear in the response body. If the keyword is found, the check fails. Case-insensitive. Max 500 characters.
Custom request headers	(none)	Additional HTTP headers to send with every request -- for example an Authorization bearer token, an API key, or a custom User-Agent.
HTTP basic auth	(none)	A username and password sent as HTTP Basic Authentication. Only for this check: without it, the uptime check uses the monitor's site access, which every check of the monitor uses.
Query parameters	(none)	Extra query-string parameters appended to the request URL.
Request body	(none)	A request body to send with POST or PUT requests -- useful for monitoring endpoints that expect a payload.
Origin-IP pinning	(none)	Pin DNS resolution to a specific IP address so the request always hits a chosen origin, bypassing the public DNS record.

Keyword Checks

Keyword checks are useful for verifying that your application is actually running and not just returning a generic error page with a 200 status code. For example:

• Set keyword present to Welcome to MyApp to verify your homepage is rendering correctly.
• Set keyword absent to Error or Maintenance to detect when your app is showing an error page.

Both keyword settings can be used together.

Response Verification Rules

For more precise verification than the simple keyword shortcuts, you can attach multiple rules that inspect the response body and headers. Each rule has a condition that determines how its value is matched:

Condition	Matches when
contains	The text appears in the target (case-insensitive).
not_contains	The text does not appear in the target.
equals	The target is exactly equal to the value.
matches	The target matches the value as a regular expression.

Body rules (response_body_rules) -- each rule is { condition, value } and is evaluated against the response body.

Header rules (response_header_rules) -- each rule is { header, condition, value } and is evaluated against the named response header (header lookup is case-insensitive). If the header is missing, the rule fails.

If any rule fails, the check status is set to fail. The simple keyword present / keyword absent settings remain available as a shortcut for the most common single-string case.

Results

Each uptime check result includes:

• Status -- ok, fail, or warning
• Response time -- Total request duration in milliseconds (including DNS, TCP connect, TLS handshake, and data transfer)
• Status code -- The HTTP status code returned by your server
• Timing breakdown -- DNS lookup, TCP connect, TLS handshake, and first byte timings
• Body size and the IP version (IPv4 or IPv6) the response came over

The monitor detail page shows a response time chart over time, making it easy to spot performance trends and correlate slowdowns with deployments or incidents.

Alerts

Incident Creation

An incident is created when:

1. The uptime check fails from the primary probe location.
2. A verification check from the secondary probe also fails.
3. The number of consecutive failures reaches the confirmation threshold (default: 1).
4. No maintenance window is currently active for the monitor.

The incident is created with the title "Uptime check failed" and severity major.

Automatic Resolution

Incidents are automatically resolved when the check passes for a configured number of consecutive successes (the recovery threshold, default: 1). A recovery update is posted to the incident: "Check recovered -- uptime restored."

Notification Events

Event	When
incident.created	Uptime check failed from both probe locations
incident.resolved	Uptime check is passing again
warning.slow_response	By default two results in a row were correct but slower than the slow response threshold (only when a threshold is set)
warning.partial_outage	By default two results in a row reached the site over one IP version (IPv4 or IPv6) but not the other
warning.cleared	A warning you were notified about is gone. Sent only for warnings that were announced, and only to the channels that received them