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 example prometheus or datadog.
• 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 Total Events and Last Event,
• 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

Uptime monitors in EvoHub can also page On-Call directly, without an integration. See Uptime alerts and silence windows. For chat, see Slack.

#How ingest works

When a tool sends to an integration URL (the API and Email integrations answer slightly differently; see their pages):

1. EvoHub checks the key. A missing, unknown or disabled key is refused with 401 and the code INVALID_KEY.
2. The parser reads the tool's payload. A body the parser cannot read is refused with 400 and INVALID_BODY.
3. Each firing alert in the payload opens an alert (or matches an open one, see below), and the integration's escalation policy starts.
4. 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.

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 the generic Webhook and for Uptime Kuma, Graylog, Splunk, Cloudflare, IBM Instana, Netdata, AWS EventBridge, Elastic / Kibana, ManageEngine OpManager, SolarWinds Orion, Sumo Logic, AppDynamics, Honeycomb, Wazuh, Checkmk, Icinga, LibreNMS, FortiGate, GitHub, GitLab, Jenkins, SonarQube and AWS CloudWatch, 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 also refuse bodies larger than 1 MiB with 413.

#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.

#Other integrations

These steps match the Show config example text in the console, where your URL is filled in for you. Replace YOUR_URL with the integration's Webhook URL.

#New Relic

1. In New Relic, go to Alerts → Destinations and add a Webhook with Endpoint URL YOUR_URL.
2. Go to Alerts → Workflows, create a workflow and notify through that webhook.

New Relic's default payload template works as-is. Alerts resolve when the issue is closed or deactivated.

#AWS CloudWatch

1. Create an SNS topic and set it as the alarm's In alarm action and its OK action (the OK action enables auto-resolve).
2. Add a subscription to the topic with Protocol HTTPS and Endpoint YOUR_URL. Leave Raw message delivery off.
3. EvoHub confirms the subscription automatically. Check in SNS that it shows an ARN rather than PendingConfirmation.

EvoHub checks the SNS signature on every message, so only messages that really come from Amazon SNS are accepted; anything else is refused with 403.

To page on CloudTrail activity through this integration, see AWS CloudTrail.

#Azure Monitor

1. In Azure Monitor, go to Alerts → Action groups and create or edit one.
2. Add an action of type Webhook with URI YOUR_URL and Enable common alert schema set to Yes. Payloads without the common alert schema are refused.
3. Attach the action group to your alert rules.

#Dynatrace

1. In Dynatrace, go to Settings → Integration → Problem notifications → Add notification → Custom integration.
2. Set Webhook URL to YOUR_URL and leave the pre-filled custom payload as it is.
3. Optionally add "ProblemSeverity": "{ProblemSeverity}" and "ProblemDetailsText": "{ProblemDetailsText}" to the payload for better severity mapping and a fuller description.

#Sentry

1. In Sentry, go to Settings → Developer Settings → Custom Integrations and create a new Internal integration.
2. Set Webhook URL to YOUR_URL, enable Alert Rule Action, and under Webhooks check issue.
3. In your alert rule, add the action that sends a notification through your integration.

The legacy Sentry "Webhooks" plugin is not supported.

#Google Cloud Monitoring

1. In Google Cloud, go to Monitoring → Alerting → Edit notification channels → Webhooks → Add new and set Endpoint URL to YOUR_URL.
2. Select this channel in your alerting policies.

An incident opening creates an alert; the incident closing resolves it.

#UptimeRobot

1. In UptimeRobot, go to My Settings → Alert Contacts → Add → Web-Hook.
2. In URL to Notify, paste YOUR_URL& — including the & at the end. UptimeRobot appends its alert data to the URL, and without the & the key is corrupted and nothing arrives.
3. No POST value is needed.

#Pingdom

1. In My Pingdom, go to Integrations → Add integration, choose Webhook and set URL to YOUR_URL.
2. Edit each check, open Connect integrations and enable the webhook. It sends nothing until it is assigned to a check.

#Site24x7

1. In Site24x7, go to Admin → Third-Party Integration → Webhook.
2. Set Hook URL to YOUR_URL, Method POST, turn on Send Incident Parameters, and turn on Post as JSON (recommended; form mode also works).

#Statuscake

1. In StatusCake, go to Contact Groups, create or edit one and set Web Hook URL to YOUR_URL.
2. Assign the contact group to your uptime tests.

StatusCake sends a fixed form post on Down and Up; there is nothing else to configure.

#Nagios

1. Add a notification command to commands.cfg (the $…$ parts are Nagios macros):

   define command {
     command_name  notify-evohub
     command_line  /usr/bin/curl -s -X POST "YOUR_URL" -H "Content-Type: application/json" -d '{"host":"$HOSTNAME$","service":"$SERVICEDESC$","state":"$SERVICESTATE$","notification_type":"$NOTIFICATIONTYPE$","output":"$SERVICEOUTPUT$"}'
   }
   

2. Set notify-evohub as the service_notification_commands of the contact your services notify.

For host alerts, use $HOSTSTATE$ and $HOSTOUTPUT$ and leave service empty. If check output may contain quotes, use a small wrapper script that JSON-escapes it.

#Cortex XDR

Requires Cortex XDR 5.x or later, or XSIAM 3.x or later.

1. Go to Settings → Configurations → Integrations → External Applications → Add Application → Webhook and set URL to YOUR_URL.
2. Go to Settings → Configurations → General → Notifications, add a Forwarding Configuration and pick the issues to forward.

Cortex sends its own issue JSON, which EvoHub reads natively.

#OpenSearch

1. In OpenSearch, go to Notifications → Channels → Create channel, choose Custom webhook, set Define endpoint by to Webhook URL and paste YOUR_URL. (In "Custom attributes URL" mode, the ?key= part is dropped.)

2. The default action message works as-is. For richer fields, replace the monitor trigger's action message with:

   {
     "monitor": "{{ctx.monitor.name}}",
     "trigger": "{{ctx.trigger.name}}",
     "severity": "{{ctx.trigger.severity}}",
     "message": "{{ctx.trigger.name}}",
     "period_start": "{{ctx.periodStart}}",
     "period_end": "{{ctx.periodEnd}}"
   }
   

The channel's Send test message creates a real test alert, so the whole path, paging included, is exercised. OpenSearch sends no recovery notification; resolve these alerts in EvoHub.

#Related

• Alert API and generic webhook
• 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