No integration to install

If it can POST a webhook, it works with CallPing.

There’s no integration to install, no authorization screen to click through, no app to approve. Setup is a CallPing webhook URL pasted into whatever tool is already generating your alerts, plus one test alert. That’s the entire integration.

See how it works

Fig 01 — The whole integration · a URL in your tool’s webhook field

Setup

The same three steps, every time

An endpoint in the portal.

An endpoint links to a scenario — the routing rules that decide who gets called. Creating one returns a unique URL immediately.

That URL in the monitoring tool.

Most monitoring and uptime tools call the field a “webhook URL,” “outgoing webhook,” or “webhook integration” in their alert settings. The CallPing URL goes in there. Nothing gets installed.

Severity mapping (or not — we’ll guess).

If your tool sends a field named severity, status, level, priority, alert_type, or similar, we read it automatically and normalize it to critical/major/minor/info. If it doesn’t, a routing rule can match on whatever field or message text your tool actually sends.

The last step is a test alert: if the routing rule matches, the phone assigned to that rule rings within a few seconds — the round-trip is webhook in, queue, Asterisk, SIP, carrier. Most of any delay you’ll notice is on the carrier side, not ours.

Full step-by-step walkthrough

Compatible sources

Tools people actually point at CallPing

Note on “compatible with”: these are tools that send webhooks in shapes we already parse, or that expose a generic outgoing-webhook in their own settings. There is no partnership, integration marketplace, certification, or vendor relationship implied anywhere on this page — every tool below is your existing vendor, sending an HTTP request to a URL CallPing generates.

Monitoring & observability

Datadog

A webhook integration in Datadog’s alert settings, pointed at a CallPing URL. Datadog’s priority field maps to severity automatically.

Grafana

A Webhook contact point in Grafana Alerting. Grafana’s status and commonLabels.severity fields are picked up out of the box.

Prometheus Alertmanager

A webhook_config receiver pointed at a CallPing endpoint. Reads status and labels.severity.

Sentry

A webhook integration on a project’s alert rules. Sentry’s level field maps directly.

New Relic

A webhook destination on a Workflow notification. The default payload’s priority field is read as severity.

Uptime & synthetic monitoring

UptimeRobot

A Web-Hook alert contact using UptimeRobot’s default POST format.

Better Stack

An outgoing webhook on an incident policy. The structured payload parses cleanly out of the box.

Statuscake

A webhook URL on a test’s contact group.

Healthchecks.io

A Webhook integration on a project; the grace-period-expired payload is what triggers the call.

Hyperping

A Webhook channel on a project’s notification settings.

Platforms & scripted alerts

Stripe

A webhook endpoint under Developers → Webhooks, filtered to the events worth a phone call (charge.dispute.created, radar.early_fraud_warning.created, and similar).

GitHub Actions

A curl step in a workflow that POSTs to a CallPing endpoint on job failure. Useful for nightly build or deploy failures nobody’s watching the Actions tab for.

Jira

A webhook action on an automation rule, pointed at a CallPing URL, fired on whatever condition is worth a phone call — an issue moving to a Highest-priority status, or a specific label being applied.

Make.com

An HTTP module at the end of a scenario, POSTing to a CallPing URL. Useful when the alert-worthy event isn’t a monitoring tool at all — a form submission, a spreadsheet row, a status change somewhere else in a workflow you’ve already built.

AWS CloudWatch

CloudWatch doesn’t POST webhooks directly, so this one goes through a small Lambda forwarder triggered off an Amazon SNS (Simple Notification Service) topic. Heavier setup than the others on this page, but still a one-time wire-up, not an ongoing integration to maintain.

Custom scripts and anything else

If it can run curl, call fetch, or fire an HTTP POST from a cron job, a continuous integration (CI) pipeline, or a five-line script, it works. The minimum viable payload is one field:

Minimum viable payload

curl -X POST \
  https://api.callping.app/api/wh/YOUR_ENDPOINT_UUID \
  -H "Content-Type: application/json" \
  -d '{"severity": "critical",
       "message": "Backup job failed"}'

We accept any HTTP method and any payload shape. JSON bodies and query-string parameters are parsed into individual fields you can route on; anything else — including form-encoded bodies — is captured whole as the alert message text.

Any JSON shape works

Your tool doesn’t have to know CallPing exists.

Routing rules don’t require a specific field name. If your payload has a recognizable severity field, we read it automatically. If it doesn’t — or if what you actually want to route on is the alert’s message text, not a severity code — routing rules can match directly on the alert content: contains, starts_with, exists, gt, and eight more operators, applied to any field your tool sends, including the message body itself.

Concretely: a payload with {"client": "acme-retail", "text": "…5xx…"} and no severity field anywhere can still route correctly — one rule matches client with equals acme-retail and routes to that client’s team; another matches the message text contains "5xx" and routes to critical-only phones. You’re not stuck rewriting your monitoring tool’s alert format to satisfy ours.

This is also what makes tools with nested or unusual payload shapes workable without a code change on your side — see the wrapper note below for the handful that need one.

See the full routing rules reference

One extra step

A few payloads need one extra step

A small number of tools nest severity inside an object rather than sending it as a top-level field. CallPing’s field matching (including content-based matching) reads any field path it’s pointed at; the only extra step is confirming the exact field name once during setup:

PagerDuty (sending events to CallPing). A custom payload template promotes the nested event.severity field, or a rule matches directly on the field path CallPing exposes.
Opsgenie (sending events to CallPing). Same pattern — a custom payload template, or a contains rule on Opsgenie’s details.priority field.
AWS CloudWatch via SNS. A small Lambda forwarder reshapes the SNS message into a flat JSON body before it reaches CallPing.

Scope, honestly

What we don’t have

No native installable plugins. No Datadog plugin, no Grafana datasource. Both tools already support outgoing webhooks natively; a plugin would add a dependency without adding a feature.
No integration marketplace or certified-partner program. The webhook URL is the integration. There’s nothing to install, authorize, or maintain a version of.
No pre-built mapper for every vendor’s exact payload shape. Most tools’ severity lives at the top level or in a field we already read. The exceptions are the handful listed above.
No AI reading your payload aloud. Whatever tool triggers the call, what rings on the other end is a plain phone call — no recorded voice, no text-to-speech summary of the alert. The call itself is the signal; you still open the source tool to see what’s wrong.

Coming next

Two things we’re building next

Browser extensionPlanned

Quick access to your alert history and shift handoffs, without opening the portal.

SMS & email deliveryPlanned

Additional alert channels alongside phone calls, for alerts that don’t need to wake someone up.

It fits whatever you already run.

No agent, no SDK, no plugin to approve — one webhook URL in the alert config you already have.

Nothing rings for visitors yet — we’re gathering interest ahead of launch. Use the button above to get on the list.