Troubleshooting
This page collects the problems people meet most often, in the order to check them. Most answers start in the same place: an alert's timeline in On-Call → Alerts records every notification EvoHub sent, held back or skipped, and why.
I didn't get a notification
Open the alert in On-Call → Alerts and read its timeline. It says who was notified, on which channel, and why a notification was not sent. The usual reasons:
- Nobody was targeted. The integration has no escalation policy (the alert is recorded, but nobody is paged), or the step targeted a schedule with nobody on call at that moment. See Escalation policies and Schedules and rotations.
- The step has not run yet. A step runs after its Notify after delay. With a first step of 5 or 15 minutes, an alert that resolves sooner pages nobody.
- It was a repeat. An alert with the same fingerprint as one that is still open is recorded as Retriggered on that alert, and nobody is paged again. See Deduplication.
- A maintenance window was running. On-Call pages nobody during maintenance; the timeline says the notification was suppressed by maintenance. See Maintenance windows.
- Your notification schedule held it back. A rule in My Account → Notifications → Notification schedule did not allow that channel at that time. See Notification schedule.
- The channel is not set up.
- Phone Call needs a verified phone number.
- Mobile Push needs you signed in to the EvoHub app on a device, with notifications allowed in the phone's settings. Profile → Push Notification Devices in the app lists the devices that receive push. See Mobile app.
- Email goes to your account email; check your spam folder.
- You are not allowed to respond. People in rotations, escalation steps and overrides must hold the permission to respond to alerts. See Roles and permissions.
- The free allowance is used up. When an organization has used its free monthly allowance and has no card or credit on file, alerts are still recorded but notifications are held back, and the timeline says so. See How billing works.
To test the whole path, create an alert with On-Call → Alerts → New Alert and pick an escalation policy whose first step targets you. See Quickstart.
Note
EvoHub does not send SMS yet; SMS is coming soon. Use push or phone calls for urgent paging.
An alert did not open
Start with what the monitoring tool says about its last delivery (most tools keep a delivery or action log), then check the integration in On-Call → Integrations: Last Event shows when EvoHub last heard from it.
| What you see | What it means |
|---|---|
The tool shows 401 with INVALID_KEY |
The key in the URL is wrong, or the integration is disabled or deleted. Copy the Webhook URL again; Enable the integration if it is disabled. |
403 with INVALID_SIGNATURE or SIGNATURE_REQUIRED |
The integration has a signing secret, and the delivery's signature is missing or wrong. See Signing secrets. |
400 with INVALID_BODY |
The body is not JSON EvoHub can read for that tool. Check the body template against the integration's page. |
413 |
The body is larger than 1 MiB. |
503 with INGEST_UNAVAILABLE |
A brief problem on EvoHub's side. The tool should retry; most do on their own. |
200, but no new alert |
The delivery was read but opened nothing: it was a recovery, the tool's own test notification (answered with "test": true), or a repeat of an alert that is still open (see Retriggered on that alert). |
| An alert titled <tool> alert (payload could not be read) | The tool's body template produced broken JSON. Fix the template, then resolve that alert by hand. See Bodies that cannot be read. |
| Last Event never changes | Nothing reaches EvoHub. Check the URL in the tool, and that the tool's alert rule actually uses the webhook, contact point or media type you created. |
If alerts open but never resolve, the tool is not sending its recovery notification, or sends it with different identifiers than the alert it should close. Each integration page says how to turn recoveries on.
Per-integration troubleshooting
These pages have a troubleshooting section for their tool: Prometheus, Grafana, Datadog, Zabbix, PRTG, Uptime Kuma, New Relic, Azure Monitor, Dynatrace, Sentry, Google Cloud Monitoring, UptimeRobot, Pingdom, Site24x7, StatusCake, Nagios, Cortex XDR, OpenSearch and KOI.
For every other tool, its page in Integrations explains what EvoHub reads and when an alert resolves, which is usually where the answer is.
Uptime monitors
A monitor that goes down opens an On-Call alert only if it has an Escalation Policy under Alerting. While a silence window covers a monitor, its alerts are muted; it keeps checking. See Uptime alerts and silence windows.
A status page is not updating
- Incidents appear only when published. An incident in On-Call reaches a status page only after you choose Publish to status page on it. From then on, its timeline notes, status changes and resolve follow it to the page. See Incidents and maintenance.
- Give it half a minute. Changes in the console and incidents published from On-Call reach visitors within about 30 seconds, and an open page refreshes itself.
- A component synced to a monitor follows the monitor. Its status cannot be set by hand. See Components and groups.
- Impact None changes no colour. An incident published with impact None shows on the page, but leaves the components' colour and the uptime percentage as they were. See Uptime bars and percentage.
- The page says "This status page is not configured". The page was taken offline. Choose Publish status page on the banner in Settings.
- Nothing at all on your domain. The domain is not verified yet; see the next section.
A custom domain is not verifying
Status pages, docs sites and changelogs connect a domain the same way: two CNAME records, added in order.
- Check the hostname. It must be a subdomain such as
status.example.com; apex domains such asexample.comare not supported. A hostname can serve only one status page, docs site or changelog. - Check the validation record. The
_acme-challengeCNAME must match the console exactly, name and value. Some DNS providers add your domain to the name on their own, so_acme-challenge.status.example.combecomes_acme-challenge.status.example.com.example.com; in that case enter only_acme-challenge.status. - Then the routing record. The subdomain's CNAME must point to
cname.evohub-dns.com. - Cloudflare. If the domain's DNS is on Cloudflare with the proxy on, set SSL/TLS to Full, not Flexible.
- Wait, then Re-check. DNS changes can take a while to spread, depending on the records' TTL. The console keeps checking while the domain is Pending DNS or Validating; Re-check checks now.
- Action needed means the domain was blocked or its certificate expired. Check that both records are still in place exactly as shown and choose Re-check. If it stays that way, remove the domain and connect it again.
Keep both records for as long as you use the domain: the certificate renews through the _acme-challenge record. See Status page custom domain, Docs custom domain and Changelog settings.
Still stuck?
Open a ticket from Help & Support in the console and include what you checked. For a failed API call, add the X-Request-ID from the response. See Get help.

