Monitors

What is a monitor?

A monitor is an active probe that the platform runs on a schedule. At each interval, a prober node sends a request to your endpoint and records the result: status, response time, and any errors. If the result does not match your configured expectations, a failure is counted.

A typical monitor's 90-day record looks like this, where each segment is one day of check history. Hover any day to see the exact uptime percentage.

Monitor types

HTTP monitors include several sub-checks layered on the same probe: keyword matching, SSL-certificate expiry, and WHOIS/domain expiry. These are options on an HTTP monitor, not separate monitor types.

Check interval

The check interval determines how often the prober sends a request. Shorter intervals detect outages faster and come with higher Uptime plans.

HTTP monitor configuration

Beyond the URL and interval, an HTTP monitor exposes several optional fields:

Authenticate the request

To monitor an authenticated endpoint, add headers in the Request headers field:

Authorization: Bearer your-api-token
X-API-Key: your-key

POST / PUT requests

Select POST as the HTTP method, set Content-Type: application/json in headers, and add a body:

{ "ping": true }

Keyword checks

Use a keyword check when HTTP 200 isn't enough — for example when a site serves a cached error page with a 200 status:

• Must contain: keyword "OK" must be present, so an {"status":"error"} response alerts.
• Must not contain: negate the check so the response alerts if a string such as "maintenance" appears.

Failure conditions

An HTTP monitor records a failure when any of these occur:

• Response HTTP status is outside the expected range (default: 2xx)
• No response within the configured timeout (default: 30 seconds, always capped below the check interval)
• SSL certificate is expired or invalid
• Response body does not contain the required keyword (when keyword check is enabled)

Alert threshold

The alert threshold is the number of consecutive failures required before an alert is opened. This prevents transient network blips from waking up your on-call team. The default is 2 consecutive failures.

• Default: 2 consecutive failures before an alert opens
• Retry on fail: the prober re-checks itself, so 1 confirmed failure is enough
• Confirmation threshold: a fixed count you set (for example 3) that overrides the above

Once an alert opens, it stays open until the monitor recovers (all checks pass) or a team member manually closes it.

Monitor status

Degraded state

A monitor can show Degraded in two distinct situations, and they behave differently:

• Partial regional outage — some prober regions fail while others still succeed. This opens an alert at warning severity (not critical), so it flows through your normal notification channels as a lower-priority signal rather than a full page. Whether a partial outage should instead be treated as critical is a per-monitor setting (see Alert & incident flow, Step 1).
• Slow response — the response time exceeds the configured slow threshold (for example, above 2 000 ms). This affects the displayed status only. It does not open an alert and does not send a separate notification; it is a health signal shown on the monitor and status page, not a paging trigger.

Degraded is an intermediate state between Up and Down.

Prober regions

Checks are sent from geographically distributed prober nodes. Each check result is tagged with its originating region.

On Uptime Free, monitors run from a single region (Nuremberg by default). On every paid Uptime plan (S, M, L), you can assign multiple regions to a single monitor. Checks then run in parallel:

• All regions fail → status: Down
• Some regions fail → status: Degraded

The monitor's alert dedup mode (deduplicated by default, or per_region) and an optional region quorum control how multi-region failures turn into alerts (see Alert & incident flow, Step 1).

Configure multi-region checks

1. Open a monitor's settings.
2. Go to the Regions tab.
3. Select one or more regions to run checks from.
4. Save. Checks start immediately from all selected regions.

All selected regions probe the endpoint independently and in parallel, so multi-region monitoring is not slower — results arrive within the check interval.

Multi-region FAQ

How is uptime calculated with multiple regions? Uptime is the percentage of successful checks across all regions — every check from every region counts equally (up checks ÷ total checks). It is not a "majority of regions" vote. So if one of four regions is failing for a stretch, that region's failed checks pull the uptime number down for that period. The majority/quorum logic applies only to alerting (when to open an incident), not to the uptime percentage. If all regions fail the monitor status is Down; if only some fail it is a partial regional outage.

Can I add more monitoring locations? New locations are added over time. Contact support if you need a specific region and we'll let you know when it becomes available.

Screenshots on failure

HTTP monitors on a paid Uptime plan can enable Capture screenshots on failure (a per-monitor opt-in, off by default). When set, HowlOps grabs a screenshot of the page a few seconds after the alert opens (see Alert & incident flow, Step 2).

Monitor dependencies

If one service depends on another (for example, your app depends on its database), link them as a dependency so a shared-cause outage does not page you multiple times. On a monitor, add an upstream monitor it depends on. While that upstream (parent) monitor is down, HowlOps suppresses the individual alert for the dependent monitor — the incident is still recorded and marked "suppressed by dependency", but the page is withheld because the parent's own outage already alerted you. When the parent recovers, dependent monitors alert normally again.

Dependencies are managed from the monitor's dependency graph (upstream and downstream links). Only a primary upstream dependency suppresses alerts.

Correlation

Separately from dependencies, HowlOps automatically correlates alerts that fire close together in time and shows a grouping banner ("N monitors affected") on the related alerts. Correlation is a view only — it does not merge or silence anything, and every individual alert still fires and pages on its own. There is no "Correlation Groups" screen to set up; it happens automatically. The correlation window and group threshold are per-workspace settings currently exposed through the API rather than a dedicated screen. To actually suppress child alerts, use monitor dependencies above.

SSL monitoring

For HTTPS monitors, SSL monitoring checks the validity and expiry of the TLS certificate on every probe cycle. Two expiry warnings are sent:

• Warning (severity: warning): 30 days before the certificate expires
• Critical (severity: critical): 7 days before the certificate expires

Each warning fires once per certificate and re-arms automatically when the certificate renews. SSL warnings are delivered through your configured notification channels and do not count as outage time in uptime calculations.

Related

• Concepts: Alert & incident flow
• Getting started: First monitor
• Concepts: Incidents
• Multi-region checks