Inbound alert sources

You do not need to replace the alerting rules you already have. Point them at AlertKick and everything downstream - escalation, on-call, Slack, Telegram, WhatsApp, SMS, email, mobile push - happens here. This page covers alerts coming in. For where they go out, see Notification channels.

Supported sources

Every source below is an integration type you can create from Admin -> Integrations -> Add. Each tile there carries a Quick Start with the exact configuration for that product.

	Source	Category	Auto-resolves when	Dedupe key
	Prometheus / Alertmanager	Metrics	status is resolved	fingerprint
	Grafana	Metrics	status is resolved (unified alerting), or legacy state ok / paused	Alert group key
	Datadog	Metrics	Transition Recovered or status OK	Alert ID
	New Relic	Observability	State closed	Issue ID
	Dynatrace	Observability	State RESOLVED	Problem ID
	Splunk	Observability	No resolve signal; resolve in AlertKick	Saved search name
	ElastAlert 2	Observability	No resolve signal; resolve in AlertKick	Rule name
	AWS CloudWatch (via SNS)	Cloud	NewStateValue is OK	Alarm name + region
	Azure Monitor (common alert schema)	Cloud	monitorCondition is Resolved	Alert ID
	Google Cloud Monitoring	Cloud	Incident state closed	Incident ID
	Nagios	Infrastructure	NOTIFICATIONTYPE is RECOVERY	Host + service
	Icinga 2	Infrastructure	NOTIFICATIONTYPE is RECOVERY	Host + service
	Zabbix	Infrastructure	Recovery action	Trigger ID + host
	Checkmk	Infrastructure	RECOVERY, service OK, or host UP	Object key
	PRTG	Infrastructure	Sensor status Up	Sensor ID
	UptimeRobot	Uptime	alertType 2 (Up)	Monitor ID
	Pingdom	Uptime	State UP / SUCCESS	Check ID
	StatusCake	Uptime	Status Up	Test ID
	Site24x7	Uptime	Status UP	Monitor ID
	Sentry	Error tracking	Issue resolved	Issue ID
	Rollbar	Error tracking	resolved_item event	Item ID
	Bugsnag	Error tracking	Error status fixed (snoozed and ignored stay open)	Error ID
	Honeybadger	Error tracking	Event resolved or up	Fault ID
	GitHub Actions	CI/CD	Next workflow_run with conclusion success	Repository + workflow
	GitLab CI	CI/CD	Next successful pipeline	Project + pipeline ref
	Jenkins (Notification plugin)	CI/CD	Build status SUCCESS	Job name
	Generic webhook	Anything	No resolve signal; resolve in AlertKick	description text
	Email	Anything	Subject prefixed resolved:, recovered:, or ok:	Normalised subject

Heartbeats are a separate product surface with their own ping URL, and Slack is an outbound channel with its own OAuth install; neither goes through the endpoint below.

Create an integration and get its key

1. Admin -> Integrations -> Add, pick the source, give it a display name that a human will recognise in an alert (“Prod Alertmanager”).

2. Choose an escalation policy. If you leave it blank the account’s default policy is bound, so a new integration always notifies someone.

3. Save. The completion screen shows the two things every sender needs:

   • Endpoint: https://<your-subdomain>.alertkick.com/api/v1/alerts
   • Service key: a per-integration secret, shown once here and masked afterwards on the integration page.

The endpoint is the same for every integration in your workspace; the key is what identifies which integration (and therefore which escalation policy) a payload belongs to. Send it as the X-Service-Key header. Senders that cannot set headers - StatusCake, Site24x7, Honeybadger, Rollbar, Bugsnag, GitHub, GitLab, Jenkins - append ?service_key=<key> to the URL instead; the Quick Start for those sources is already written that way. Prefer the header where you have the choice, because URL keys end up in proxy and edge logs.

A wrong or missing key returns 401 Invalid Service Key. A successful ingest returns the created (or re-triggered) alert as JSON.

On the integration’s page you can:

• Send Test Alert - fires a canned sample for that source through the real pipeline, flagged is_test_alert, so you can watch it reach the right people before wiring the sender.
• Ingest log - every request to the endpoint for this integration, with source IP, user agent, content type, response status, and the raw body (up to 64 KB), retained for 7 days. This is where to look when “it sent, but nothing happened”.
• Regenerate key - rotates the secret; the old one stops working immediately.
• Retire or delete the integration.

For AWS CloudWatch and Google Cloud, subscribe the endpoint as an SNS or Pub/Sub push target; the subscription confirmation handshake is handled automatically.

Default severity

Each integration has a Default Severity (critical, high, warning, info, or unset), edited on the integration page or via PATCH /api/v1/alertservices/{uuid}/default-severity.

It is a fallback only. When the payload carries a severity - a Prometheus severity label, a Datadog priority, a Nagios state - that value is stored as sent and the default is ignored. The default fills the gap for senders that say nothing, most commonly the generic webhook, email, and host-monitoring notifications with no severity macro. Payload wins; default never overrides. Escalation treatment per severity is decided by the bound policy, see Escalation policies.

Dedupe and auto-resolve

Every source handler finds an already-open alert (triggered or acknowledged) from the same integration with the same dedupe key before creating a new one. A repeat notification increments the alert’s trigger count and adds a “re-triggered” activity; it does not page again. The key column in the table above is what “same” means for each source.

When the source sends its recovery signal, AlertKick resolves the open alert on your behalf, records a Recovery activity, and answers {"status":"resolved","alert_uuid":"..."} - or {"status":"no_open_alert"} if there was nothing to close. Splunk, ElastAlert, and the generic webhook have no recovery signal; those alerts are resolved by a person, from the dashboard, the mobile app, or the API.

Alerts that arrive during an active maintenance window are suppressed.

Generic webhook payload

For anything not in the table, POST JSON with these fields:

Field	Required	Used for
subject	No	Alert title; built from the source and hostname if omitted
description	Yes in practice	Alert body, and the dedupe key: identical descriptions re-trigger the same open alert
hostname	No	Shown on the alert and used in the generated subject
severity	No	Stored as sent; falls back to the integration’s default severity
generated_by	No	Recorded in the activity as “Triggered by …”

curl -X POST https://<subdomain>.alertkick.com/api/v1/alerts \
  -H "Content-Type: application/json" \
  -H "X-Service-Key: <service key>" \
  -d '{"subject":"Disk 91% on db-2","description":"/var 91% used on db-2","hostname":"db-2","severity":"warning"}'

Keep description stable for the same condition so repeats collapse into one alert, and vary it when the condition is different.

Email

An Email integration is given its own ingest address of the form <subdomain>.<integration-id>@alerts.alertkick.com. Anything that can send mail can raise an alert: point the sender’s notification email at that address. Plus-suffixes (...+nagios@) are accepted so one address can be reused across senders.

• Title is the subject. Body becomes the description.
• Severity comes, in order, from a subject marker (critical, down, outage, failure -> critical; warning or warn: -> warning; info -> info), then a severity field in the body, then the integration default, then warning.
• Dedupe uses the subject with Re:/Fwd: stripped, lowercased, whitespace collapsed.
• A subject starting resolved:, [resolved], recovered:, [recovered], ok:, or [ok] resolves the matching open alert.

The address is the credential; treat it like a key and regenerate the integration if it leaks.

Importing from Opsgenie or PagerDuty

Admin -> Import (also reachable from the Migrate tiles in the integration catalogue) copies your existing on-call setup:

1. Choose the provider and paste a read-only API key (and, for Opsgenie, the US or EU region). The key is used for this request only and is never stored.
2. Preview fetches users, schedules, and escalation policies and shows the plan with warnings - nothing is written.
3. Apply creates rosters from schedules and escalation policies from policies. Users are matched by email address; unmatched users are listed, not created. Existing names are skipped, so re-running is safe.

Current mapping limits: the first rotation layer of each schedule with daily or weekly rotation is imported (other layers and restrictions are recorded as notes on the roster), team targets in policies are skipped, and repeat counts are capped at 10. See Roster management for editing the result.