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 monitor detail visualises its retained check history. The retention window comes from the workspace's live Uptime capability.

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.

See TCP monitoring and DNS monitoring for the full configuration and behavior of those two types.

Check interval

The check interval determines how often the prober runs the check. The monitor form reads the current minimum from the workspace capability and prevents a value below it. See pricing for the current plan comparison.

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 is not 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
• SSL certificate is expired or invalid
• Response body does not contain the required keyword (when keyword check is enabled)

Alert threshold

The confirmation threshold is the number of consecutive failures required before an alert opens. It prevents one transient result from immediately waking the on-call team when the configured policy requires confirmation.

• Retry on fail asks the prober to repeat a failed attempt.
• Confirmation threshold controls how many confirmed failures must accumulate.

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 the online regions selected on the monitor. The picker and the public probers endpoint are the live source for available locations. With multiple regions, checks run independently:

• 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 regions in the monitor editor. See Probing regions for aggregation, outage verification, and current location discovery.

Multi-region FAQ

How is uptime calculated with multiple regions? Uptime is the percentage of successful checks across all regions: every check from every selected region counts equally (up checks ÷ total checks). It is not a "majority of regions" vote. If one selected region fails for a while, its failed checks lower the uptime percentage 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.

The addresses we probe from

Every check comes from one of our probing servers, and those have fixed addresses. If a firewall, CDN or WAF in front of your site blocks them, your monitor reports the site as down while it is perfectly healthy for everyone else.

The list is published two ways:

• howlops.com/bot: a page explaining what the checks are, how often they run, and how to block them deliberately if you would rather we stopped.
• GET /api/v1/public/probers: the same list as JSON, so a firewall rule can read it directly rather than someone copying addresses by hand.

Only servers that are actually in service are listed. A block usually shows up as a 403 from every region at once, while the site loads fine in your browser: if you see that, this is almost certainly the cause.

Screenshots on failure

HTTP monitors can enable Capture screenshots on failure when the workspace has screenshot_monitoring. This is a per-monitor opt-in and is off by default. When enabled, HowlOps captures the page 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.

Where the time goes

For HTTP monitors, the detail page breaks a request into its phases and charts them over the same window as the response-time chart above it:

Time to first byte is measured from the beginning of the request, so it already includes the three phases above it. Read it as the whole against its parts: when the total climbs and the three phases do not, the extra time is the server thinking.

A gap in one of the phases is not an error. A check that reuses an already-open connection does no lookup and no handshake, so those phases have nothing to report for that check.

SSL monitoring

For HTTPS monitors, SSL monitoring checks the certificate's validity and expiry. The platform's current warning and critical thresholds decide when certificate events are created.

Each warning fires once per certificate and re-arms when the certificate renews. SSL warnings do not count as outage time in uptime calculations.