Troubleshooting

Find your symptom below. Each entry lists what you see, why it happens and how to fix it. Error messages are quoted exactly as SutramX shows them, so you can search this page for the text you see.

When you open a failing monitor, the check history shows the error for each region. Start there: it usually tells you which section below applies.

Monitor blocked by a firewall, WAF or Cloudflare#

Symptoms

• Checks fail with Blocked by bot protection (WAF) and a message like Blocked by Cloudflare bot protection (HTTP 403) — the target refused the check, so its availability could not be verified.
• Or checks fail with Received HTTP 403, Received HTTP 429 or Received HTTP 503 while the site works in your browser.
• Some regions pass and others fail.

Cause. Your firewall, CDN bot protection (Cloudflare, Vercel, AWS WAF, Akamai, Imperva, Sucuri and others), a WordPress security plugin or a rate limiter is refusing SutramX's requests. Datacenter traffic is often challenged by default.

Fix

1. Allowlist the checker. The simplest rule matches the user agent substring SutramX-Monitor. For a stricter rule, allowlist the IP addresses at sutramx.com/bot/ips.txt.
2. Follow the step-by-step instructions for Cloudflare, Vercel, AWS WAF, nginx, Apache and WordPress at sutramx.com/bot. On Cloudflare, see the notes below.
3. Or add a custom request header with a secret value to the monitor and allow that header in your firewall. See HTTP & keyword monitors.
4. Exempt the checker from rate limiting too. Every region a monitor uses checks on each interval, which can trip a strict limit.

On Cloudflare:

• Free plan with Bot Fight Mode on: Bot Fight Mode cannot be bypassed by WAF custom rules, a Skip action or Page Rules, and a user agent rule does not help. Add an IP Access Rule with the action Allow for each address in /bot/ips.txt (Security → WAF → Tools → IP Access Rules); Bot Fight Mode does not challenge a request an IP Access Rule has already allowed. Or turn Bot Fight Mode off.
• Pro and above (Super Bot Fight Mode): create a custom rule matching the SutramX addresses with the action Skip and select All Super Bot Fight Mode rules.
• A WAF custom rule expression on its own only skips managed rules, rate limiting and your custom rules, not Bot Fight Mode.
• SutramX has applied to Cloudflare's Verified Bots program and signs its requests with Web Bot Auth; until Cloudflare approves it, use the rules above.

If you can't change the firewall, untick Blocked by bot protection (WAF) under Alert on these HTTP errors in the monitor editor. Checks still fail, but no alerts are sent. See Regions & confirmation.

False or unexpected down alerts#

Symptoms. You got a down alert, but the site looked fine when you checked.

Causes and fixes

On multi-region plans, an incident only opens when enough regions agree. See Regions & confirmation.

A monitor keeps going up and down#

If a monitor goes down again within 5 minutes of recovering, the incident is reopened and marked as flapping, and the repeat alert is held back. Raise Failure threshold and Recovery threshold to smooth out an unstable target, and look for the underlying cause (an overloaded server, a failing instance behind a load balancer).

A monitor shows Degraded#

Degraded means either the response was slower than Degraded above (ms), or a check failed in some region without enough regions agreeing to open an incident. Degraded never sends a down alert. Open the monitor to see which region failed and why.

Not receiving alerts#

Symptoms. An incident opened (it shows on Incidents), but you got no email, chat message or page.

Open the incident first. If its alert was held back, it says why:

If nothing was held back, check delivery:

1. Email recipients are verified. Alerts only go to verified addresses. New recipients get a one-time confirmation email that must be accepted. Check the alert recipients list.
2. Spam folder. Add SutramX's sending address to your contacts or allowlist.
3. Unsubscribed. If a recipient used the unsubscribe link in an alert email, they no longer get alert email for the workspace.
4. Chat and webhook channels. Check the connection is still active, and that it is routed to this monitor or its group.
5. SMS, WhatsApp and voice. These use alert credits. When credits run out, those channels stop sending. See Alert credits.
6. Escalation policy. If the monitor uses an escalation policy, later steps only fire after their delay and stop once someone acknowledges.

Use Send test notification in the monitor page's menu to test delivery end to end.

No recovery alert#

A recovery alert is only sent if a down alert was sent for that incident. If the outage started and ended inside a maintenance window or quiet hours, neither is sent. With Monitor Recovery Alerts switched off, recovery emails stop but connected channels still get the recovery.

Heartbeat not received#

Symptoms. A heartbeat monitor reports No heartbeat received for the run expected at … although the job ran, or Last heartbeat says "None received yet".

Test the URL by hand from the machine that runs the job:

curl -v "https://YOUR-HEARTBEAT-URL"

Other common causes:

• Time zone. The cron expression is always UTC. A job scheduled at 02:00 local time in a UTC+5:30 zone runs at 20:30 UTC the day before. Convert the schedule to UTC.
• Grace period too short. Ping at the end of the job and set Grace period (minutes) longer than the job's longest normal run.
• The ping never runs. With job && curl …, curl only runs if the job exits with code 0. Check the job's own logs.
• curl is missing in a minimal container image. Install it or use another HTTP client.
• The job reported a failure. A ?status=fail ping keeps the monitor down until a successful ping arrives. The check shows Job reported failure at ….

SSL and TLS errors#

Symptoms. HTTP checks fail with one of these errors:

A common cause of "it works in my browser" is a server that doesn't send its intermediate certificate. Browsers often fill the gap; other clients don't. Configure the server to send the full chain.

Unticking Verify TLS certificates makes the check pass despite certificate problems, so only do it for systems where that is acceptable. For warnings before a certificate expires, see SSL & domain expiry.

Timeouts#

Symptoms. Checks fail with:

• Connection timed out before establishing a socket to the upstream host: no connection could be made. Usually a firewall silently dropping the checker's traffic, or the server is down.
• Read timed out while waiting for the upstream response body: the server connected but was too slow to send the response.
• Request timed out before a complete response was received: the whole request took longer than the timeout.

Fix

1. If only some regions time out, it's often a firewall or geo-blocking rule. Allowlist the checker (see above).
2. Raise Timeout (seconds) (1–60 s for HTTP and API).
3. Remember the timeout is capped at the check interval minus 3 seconds. On a 15-second interval the effective timeout is at most 12 seconds; the editor shows the effective value. Use a longer interval for slow endpoints.
4. Point the monitor at a lightweight health endpoint rather than a heavy page.

DNS failures#

Symptoms. Checks fail with DNS resolution failed, or a monitor can't be saved with We couldn't find … Check the address for typos, or that its DNS record exists.

Causes and fixes

• Typo in the host name. Check the URL or host on the monitor.
• The record doesn't exist publicly. SutramX resolves names with public DNS. Names that exist only on your internal DNS or in a hosts file can't be checked.
• Recently changed records. Wait for the record's TTL to pass.
• DNS provider outage. If all regions fail at once for several monitors on the same domain, check your DNS provider's status.
• Expired domain. See SSL & domain expiry.

Target resolves to a non-public address and cannot be monitored means the host resolves to a private, loopback or internal IP address. SutramX only checks public addresses. Expose a public health endpoint, or use a heartbeat monitor where your internal service pings SutramX instead.

Status page custom domain not working#

Symptoms. Verify fails, or the custom domain doesn't load your status page.

Custom domains need two DNS records, both shown in the status page's Custom domain panel:

After verification, the HTTPS certificate is issued automatically on the first HTTPS visit, which can take a moment. Use Check SSL in the panel to see its state. Custom domains are a plan feature (Growth and Pro); after a downgrade the domain stops serving, and the page stays available at its /status/ URL. See Branding & custom domains.

API errors#

Errors are returned as JSON with an error message and, for most errors, a code:

{ "error": "monitors limit reached", "code": "ENTITLEMENT_LIMIT_REACHED", "details": { "resource": "monitors", "plan": "free", "current": 50, "limit": 50, "upgradePath": "/subscription" } }

400 Bad Request#

{"error": "Validation failed", "errors": [{"field": "interval_seconds", "message": "…"}]} lists each invalid field. Other 400 errors explain the problem in error, for example Invalid interval. Minimum is 60 seconds for starter plan.

401 Unauthorized#

curl https://api.sutramx.com/monitors -H "Authorization: Bearer $SUTRAMX_API_KEY"

403 Forbidden#

This API key cannot manage alert channels or exports. Create an API key with automation access in Settings → API keys. means the key's access level is too low for that endpoint. See REST API.

409 Conflict#

WORKSPACE_PENDING_DELETION: This workspace is scheduled for deletion. Cancel the deletion to make changes.

429 Too Many Requests#

You sent too many requests in a time window. Responses include standard RateLimit-* headers; wait for the reset and retry with backoff. Limits apply per endpoint group, for example:

Payment problems#

Payment failed. The dashboard shows "Your last payment didn't go through". Your monitors keep running while the payment is retried. Go to Plans & billing → Billing and click Update payment method (on Razorpay, Complete payment). If the grace period ends without a successful payment, the account moves to the Free plan.

Monitors paused after a downgrade or failed payment. Monitors over your plan's limits are paused, not deleted. On Free, a banner says how many. Upgrade to resume them, or choose which ones run with Choose monitors to resume on Billing.

Upgrade still pending. "Your plan change is still waiting for payment confirmation." The payment provider can take a few minutes to confirm. You stay on your current plan until it succeeds. If your browser blocked the payment page, use the "Open payment page" link.

Card or UPI declined. "The payment didn't go through, so nothing changed." Try another card or payment method, or check with your bank. SutramX never sees your card number, CVV or UPI PIN, so we can't see why a bank declined.

For invoices, refunds and plan changes see Payments & invoices and Upgrade, downgrade & cancel.

Website health run failed#

See Website health.

Still stuck?#

Email support@sutramx.com with the monitor or status page name, the time of the problem (with time zone) and the exact error message. See Getting help.