Integrations overview
An integration connects one monitoring tool to EvoHub On-Call. It gives the tool a unique URL (or, for email, a unique address) to send alerts to, and it decides which escalation policy pages people for those alerts. This page lists every supported integration and explains how ingest works.
Add an integration
Creating, editing and deleting integrations needs permission to write integrations (Owners, Admins and Members by default). Reading the list needs permission to read integrations, because each integration carries its key.
The webhook URL and key
Each integration's URL looks like this:
https://evohub.io/ingest/<type>?key=<integration key>
<type>selects the parser for the tool, for exampleprometheusordatadog.- The integration key (shown as API Key in the integration) identifies the integration. It decides the organization and the escalation policy; nothing in the request body can override it.
- No other authentication is needed: monitoring tools cannot sign in, so the key in the URL is the credential. Treat the URL like a password. If it leaks, delete the integration and create a new one.
The API integration also accepts the key in the request body or an Authorization: Bearer header. The Email integration uses an inbound email address instead of a URL.
Signing secrets
GitHub, GitLab, Jenkins and SonarQube can prove that a delivery came from them. Their integrations have a Signing secret section:
- Generate secret creates a 64-character secret and shows it once — copy it into the tool. Rotate replaces it; the old one stops working at once.
- Use my own stores a secret already set in the tool: 16 to 256 characters, no spaces, at least 8 of them different.
- Remove goes back to the key alone.
With a secret set, EvoHub checks every delivery's signature before reading it, and refuses a missing or wrong one with 403 INVALID_SIGNATURE. The integration's key is then refused on any URL that checks no signature (403 SIGNATURE_REQUIRED), so the key alone is no longer enough. Without a secret, the key in the URL is accepted as for every other integration — the integration says Not set and suggests setting one.
The secret is stored encrypted and is never shown again, not even to admins; the integration only says Configured. GitHub and SonarQube sign the body but not the time, so a captured delivery would verify again if resent; that can only retrigger or resolve the same alert.
Manage an integration
Click an integration on the Installed tab to open it. You can:
- copy the Webhook URL and API Key,
- see Last Event, when it last received something,
- View this integration's alerts,
- Edit its name and escalation policy,
- set, rotate or remove the Signing secret (GitHub, GitLab, Jenkins and SonarQube),
- Disable it (requests are refused until you Enable it again), or
- Delete it — its URL and key stop working immediately.
An integration with no escalation policy still records alerts, but nobody is paged.
Supported integrations
The catalog has 44 integrations. AWS CloudTrail has no integration of its own: it pages through the AWS CloudWatch one, so it is listed separately below.
| Integration | Type in URL | How it connects | Auto-resolve | Setup |
|---|---|---|---|---|
| API | api |
Your own scripts and tools send JSON; trigger, acknowledge or resolve. | Send event_action: resolve with the same dedup_key. |
Alert API and generic webhook |
| Webhook | alerts |
Any tool that can POST flat JSON; also accepts flat alert_* fields. |
Send status (or alert_status) resolved with the same fingerprint or title. |
Generic alert webhook |
| Prometheus | prometheus |
Alertmanager webhook receiver. | Yes, with send_resolved: true. |
Prometheus |
| Grafana | grafana |
Grafana Alerting webhook contact point. | Yes. | Grafana |
| Datadog | datadog |
Datadog Webhooks integration, mentioned in monitor messages. | Yes, when the monitor recovers. | Datadog |
| Zabbix | zabbix |
Webhook media type with a short script. | Yes, with a recovery message. | Zabbix |
| PRTG | prtg |
"Execute HTTP Action" notification template. | Yes, when the sensor is Up again. | PRTG |
| — | A unique inbound email address. | Yes, from a follow-up email that says the issue recovered. | ||
| New Relic | newrelic |
Webhook destination used by an alert workflow. | Yes, when the issue is closed. | New Relic |
| AWS CloudWatch | cloudwatch |
SNS topic with an HTTPS subscription. | Yes, with the OK action set. | AWS CloudWatch |
| Azure Monitor | azuremonitor |
Action group webhook with the common alert schema. | Yes. | Azure Monitor |
| Dynatrace | dynatrace |
Problem notification, custom integration. | Yes. | Dynatrace |
| Sentry | sentry |
Internal integration with alert rule action. | Yes, when the issue is resolved or the metric alert resolves. | Sentry |
| Google Cloud | googlecloud |
Cloud Monitoring webhook notification channel. | Yes, when the incident closes. | Google Cloud Monitoring |
| UptimeRobot | uptimerobot |
Webhook integration (or an older Web-Hook alert contact). | Yes, when the monitor is up. | UptimeRobot |
| Pingdom | pingdom |
Webhook integration assigned to checks. | Yes, when the check recovers. | Pingdom |
| Site24x7 | site24x7 |
Third-party webhook integration. | Yes, when the monitor is up. | Site24x7 |
| Statuscake | statuscake |
Contact group webhook URL. | Yes, when the test is up. | StatusCake |
| Nagios | nagios |
Notification command that posts JSON with curl. |
Yes, on a RECOVERY notification. | Nagios |
| Cortex XDR | cortex |
Cortex XDR / XSIAM webhook forwarding. | Yes, when the issue is resolved. | Cortex XDR |
| OpenSearch | opensearch |
Alerting notification channel (custom webhook). | No — resolve in EvoHub. | OpenSearch |
| Uptime Kuma | uptimekuma |
Webhook notification. | Yes, when the monitor is up. | Uptime Kuma |
| Graylog | graylog |
HTTP Notification on event definitions. | No — resolve in EvoHub. | Graylog |
| Splunk | splunk |
Webhook alert action. | No — resolve in EvoHub. | Splunk |
| Cloudflare | cloudflare |
Notifications webhook destination. | Yes, when the alert ends or the health check is healthy. | Cloudflare |
| IBM Instana | instana |
Webhook alert channel. | Yes, when the issue closes. | IBM Instana |
| Netdata | netdata |
Netdata Cloud webhook configuration. | Yes, when the alert clears or the node is reachable. | Netdata |
| AWS EventBridge | eventbridge |
API destination or SNS topic; GuardDuty, Security Hub and AWS Health read natively. | Security Hub findings, AWS Health events and CloudWatch alarm state changes, yes; GuardDuty, no. | AWS EventBridge |
| AWS CloudTrail | cloudwatch |
Metric filter → CloudWatch alarm → SNS. | Yes, when the alarm returns to OK. | AWS CloudTrail |
| Elastic / Kibana | elastic |
Webhook connector on alerting rules, with a body template. | Yes, from the rule's Recovered action. | Elastic / Kibana |
| ManageEngine OpManager | opmanager |
"Invoke a Webhook" notification profile, with a body template. | Yes, when the alarm clears. | ManageEngine OpManager |
| SolarWinds Orion | solarwinds |
POST request action on trigger and reset, with a body template. | Yes, on reset. | SolarWinds Orion |
| Sumo Logic | sumologic |
Webhook connection, with a body template. | Yes, from the recovery payload. | Sumo Logic |
| AppDynamics | appdynamics |
HTTP Request Template on a policy action. | Yes, when the violation ends or is canceled. | AppDynamics |
| Honeycomb | honeycomb |
Webhook integration as a trigger recipient. | Yes, when the trigger is OK. | Honeycomb |
| Wazuh | wazuh |
Integrator custom integration with a script EvoHub provides. | No — resolve in EvoHub. | Wazuh |
| Checkmk | checkmk |
Notification script EvoHub provides. | Yes, on a RECOVERY notification. | Checkmk |
| Icinga | icinga |
Icinga Notifications webhook channel, or an Icinga 2 notification script EvoHub provides. | Yes, when the incident recovers or on a RECOVERY notification. | Icinga |
| LibreNMS | librenms |
API alert transport, with a body template. | Yes, from the rule's recovery alert. | LibreNMS |
| FortiGate | fortigate |
Automation stitch with a Webhook action. | No — resolve in EvoHub. | FortiGate |
| GitHub | github |
Repository or organization webhook, signed. | Yes, when the next run or deployment succeeds, or the alert is fixed. | GitHub |
| GitLab | gitlab |
Project or group webhook with a secret token. | Yes, when the next pipeline, job or deployment succeeds. | GitLab |
| Jenkins | jenkins |
Notification plugin, or curl from a pipeline. |
Yes, when the same job and branch builds successfully. | Jenkins |
| SonarQube | sonarqube |
Project or global webhook, signed. | Yes, when the quality gate passes again. | SonarQube |
| KOI | koi |
KOI webhook; the mapping is provisional. | Yes, when the alert is resolved, closed, dismissed or remediated. | KOI |
Not in the list?
Three integrations accept alerts from anything:
- API — JSON events to trigger, acknowledge and resolve alerts by
dedup_key. It reads the Events API v2 format other paging tools use as it is (the same body,dedup_keyand202answer), so a tool or script that already sends Events API v2 only needs the new URL and key. See Alert API and generic webhook. - Webhook — any tool that can POST a JSON body, including flat
alert_*fields. See Generic alert webhook. - Email — any tool that can send an email. See Email.
Moving from another paging tool? The Opsgenie and PagerDuty importers create these integrations for you.
Uptime monitors in EvoHub can also page On-Call directly, without an integration. See Uptime alerts and silence windows. For chat, see Slack and Microsoft Teams.
How ingest works
When a tool sends to an integration URL (the API and Email integrations answer slightly differently; see their pages):
- EvoHub checks the key. A missing, unknown or disabled key is refused with
401and the codeINVALID_KEY. - The parser reads the tool's payload. A body the parser cannot read is refused with
400andINVALID_BODY. - Each firing alert in the payload opens an alert (or matches an open one, see below), and the integration's escalation policy starts.
- Each recovery in the payload resolves the matching open alert.
The response is 200 with a count of what happened:
{
"data": { "received": 1, "created": 1, "resolved": 0 },
"success": true
}
A tool's own test notification (the Test button in Uptime Kuma, Graylog, Cloudflare, Instana, Netdata, Kibana, OpManager, SolarWinds, Sumo Logic, AppDynamics, Honeycomb and LibreNMS, GitHub's ping when a webhook is created, or the --test run of the Wazuh, Checkmk and Icinga 2 scripts) is answered with 200 and "test": true and opens no alert, so testing never pages anyone; the integration's Last Event still updates. Netdata is the one exception: its test carries a verification token you need, so it opens one info alert that pages nobody and does not count toward usage — see Netdata. Pingdom's test webhook and OpenSearch's Send test message work the other way: each opens a real alert under the integration's escalation policy, so the whole path, paging included, is exercised — see Pingdom and OpenSearch.
EvoHub answers 200 whenever the payload was read, even if it produced no alert, so that tools do not disable the webhook after repeated errors. If the key could not be checked on EvoHub's side, the answer is 503 with INGEST_UNAVAILABLE and a Retry-After header; most tools retry automatically.
Deduplication
Every alert gets a fingerprint from the tool's own identifiers — Alertmanager's fingerprint, a Datadog alert ID, a Zabbix host and trigger, a PRTG sensor ID, and so on. If an alert arrives while an alert with the same fingerprint is still open (triggered or acknowledged), EvoHub records Retriggered on the existing alert instead of opening a new one, and nobody is paged again. After the alert is resolved, the next one with that fingerprint opens a new alert. Only new alerts count toward usage; retriggers do not.
For every integration that authenticates with the key in its URL, fingerprints are kept per integration: the same fingerprint arriving through two integrations opens two alerts, and a recovery only resolves alerts of the integration it arrived on. These integrations refuse bodies larger than 1 MiB with 413, and answer 500 when an alert could not be stored, so the tool sends it again. Alerts opened before an integration's fingerprints became per-integration still resolve normally.
Bodies that cannot be read
Tools that fill in a body template you paste — Elastic / Kibana, ManageEngine OpManager, SolarWinds Orion, Sumo Logic, AppDynamics, LibreNMS and others — usually insert values without escaping them, so a line break, a double quote or a Windows path inside a value breaks the JSON. EvoHub repairs these. If a body that starts as a JSON object still cannot be read, it is not refused: EvoHub opens an alert titled <tool> alert (payload could not be read), severity high, under the integration's escalation policy, with the body exactly as received in its description and the label payload=unparsed. Sending the same body again is recorded as Retriggered. Such an alert never resolves by itself; fix the template in the tool and resolve it in EvoHub. A body that is not a JSON object at all is refused with 400.
Auto-resolve
When a tool reports that a problem has recovered, EvoHub resolves the open alert with the same fingerprint, and the escalation stops. The alert's timeline shows it was resolved by the integration. If the tool's recovery notification is not configured, alerts stay open until someone resolves them.
Severity
Each parser maps the tool's severity to EvoHub's critical, high, medium, low or info. The integration pages describe the mapping. When a tool sends no severity EvoHub recognizes, most parsers use medium; email alerts are always high.
Related
- Alert API and generic webhook
- New Relic, AWS CloudWatch, Azure Monitor, Dynatrace, Sentry, Google Cloud Monitoring
- UptimeRobot, Pingdom, Site24x7, StatusCake, Nagios, Cortex XDR, OpenSearch, KOI
- Uptime Kuma, Graylog, Splunk, Cloudflare, IBM Instana, Netdata
- AWS EventBridge, AWS CloudTrail, Elastic / Kibana, ManageEngine OpManager, SolarWinds Orion, Sumo Logic, AppDynamics, Honeycomb
- Escalation policies
- Alerts and incidents
- Migrate from Opsgenie