HowlOps
FeaturesHow it worksPricingIntegrationsDocsChangelogContact
Log inStart free
DOCS

FAQ - common errors

Answers to the most frequently asked questions about errors in HowlOps.

"Monitor limit exceeded" when creating a monitor

Your workspace has reached the monitor limit for your current Uptime plan. Options:

  • Delete unused monitors under Monitors > select monitor > Delete.
  • Upgrade your Uptime plan: Settings > Plan.

See Plan limits reference for the exact monitor limits per Uptime plan.

"Feature not available on your plan"

The feature you tried to use requires a higher plan on the relevant capability (Uptime, On-call, or Status pages). The error response includes a required_plan field. See Plan limits reference for a feature-by-capability breakdown.

Monitor is "up" but my site is actually down

Possible causes:

  • Monitor URL is wrong. Verify the URL, including https:// prefix and any path.
  • The monitor is checking a different endpoint. The health endpoint you are checking may return 200 even when the application is broken. Consider adding a content check (keyword match) in the monitor settings.
  • False positive (not yet confirmed). By default, HowlOps requires 2 consecutive failures before opening an incident to reduce false positives. The monitor status may show "up" until the confirmation threshold is met.
  • Geographic routing. The prober is connecting from a specific region. If your DNS or CDN routes that region to a different server, you may see a different result than a local curl.

Monitor is "down" but my site is fine

This is a false positive. Common causes:

  • Temporary network issue in the prober region. Single-region probers can experience brief connectivity blips. Enabling multi-region monitoring (any paid Uptime plan: S, M or L) cross-validates across regions.
  • Timeout too short. If your endpoint occasionally takes more than the configured timeout, it registers as a failure. Increase the timeout under monitor settings.
  • IP blocking. Your server or CDN may be blocking the prober's IP range. Contact support for the prober IP list to add to your allowlist.
  • TLS certificate issue. Probers validate certificates against public certificate authorities. A self-signed certificate, a certificate signed by a private/internal CA, an expired certificate, or one with a hostname mismatch is treated as a failure. Check Monitor > SSL tab for certificate details.

"Rate limited" error (429)

You have exceeded the API rate limit. See API error codes reference for limits per endpoint group. Wait for the X-RateLimit-Reset timestamp before retrying.

Heartbeat not resetting after a ping

Possible causes:

  • Wrong slug. Verify the URL you are pinging matches exactly: POST /api/v1/hb/<slug>. The slug is case-sensitive.
  • Authentication. Heartbeat pings do not require authentication by default, but if your workspace requires it, include the Authorization header.
  • Rate limit. Heartbeat pings have a configurable per-tenant rate limit.
  • Invitation links expire after 48 hours. Ask the inviter to resend.
  • If you followed the link but the workspace still does not appear, you may have accepted it into a different account. Try signing out and signing back in with the email address the invitation was sent to.

Export download links expire after 48 hours. Request a new export from Settings > Account > Data export > Request export.

Status page custom domain shows a certificate error

Certificate provisioning can take a few minutes after the CNAME record is verified. Wait 5–10 minutes and reload. If the error persists after 30 minutes, the CNAME may not be resolving correctly. Verify with:

bash
dig status.example.com CNAME

See Set a custom domain for the full setup guide.

API returns 404 for a resource I know exists

HowlOps returns 404 for unauthorized access to prevent tenant data leakage (IDOR protection). Verify:

  • You are authenticated as the correct user and workspace.
  • The resource belongs to the workspace your token is scoped to.
  • The resource ID is correct (UUIDs are case-sensitive).

How do I avoid false alarms during deployments?

Pause the monitor for the duration of the deploy and resume it afterward:

POST /api/v1/monitors/:id/pause
POST /api/v1/monitors/:id/resume

Add these calls to your CI/CD pipeline (the token needs the write scope). See Integrations → CI/CD (GitHub Actions) for a ready-made workflow, or Maintenance windows for scheduled downtime.

SSL certificate check is failing but my certificate looks valid

Probers validate certificates against public certificate authorities. Common causes:

  • Self-signed certificate — not trusted by public CAs.

  • Incomplete chain — a missing intermediate CA. Test with:

    bash
    openssl s_client -connect yoursite.com:443 -verify_return_error

  • Hostname mismatch — the certificate CN/SAN does not match the monitored URL.

Check Monitor → SSL for the certificate details HowlOps observed.

Can I monitor internal or private endpoints?

Not directly. HowlOps checks run from external cloud locations, so private services (192.168.x.x, 10.x.x.x, or anything behind a VPN) are not reachable from the probers. Options:

  • Expose a dedicated public health-check endpoint.
  • Use heartbeat monitoring — have a job inside your network ping HowlOps, so reachability is proven from the inside out.

See also

Was this page helpful?