Webhook to phone call, end to end.
The mechanic in five steps. No black box, no proprietary protocol, no monitoring agents to install on your servers — just HTTP in, a phone call out.
Your monitoring tool sends an HTTP request
Whatever tool fires alerts (Datadog, Grafana, Prometheus, a
curl in a Lambda, a GitHub Action) makes a standard
HTTP request to a unique URL we generate for you.
We accept any HTTP method (POST, PUT, PATCH, GET, DELETE). The body can be JSON, form-encoded, or query-string parameters. If JSON parse fails, the raw text is captured as the message.
The endpoint UUID is the only credential by default. You can
optionally turn on a shared X-Alert-Key header for
extra protection on shared environments.
curl -X POST https://api.callping.app/api/wh/YOUR_ENDPOINT_UUID \
-H "Content-Type: application/json" \
-d '{"severity": "critical",
"message": "Checkout endpoint 5xx"}'
CallPing extracts severity and matches a routing rule
Severity is read from any of these field names in your payload
(first found wins): severity, status,
level, priority, alert_type,
alertLevel, alert_level. Common values
like p1, critical, high,
error, warning, info,
resolved are normalized to one of critical
/ major / minor / info.
You do not rename your tool’s payload to match ours.
The endpoint is linked to a Scenario. The Scenario contains an
ordered list of routing rules. We evaluate them top-to-bottom.
The first rule whose condition matches the alert wins. No match
falls through to a default action of call_primary
so an alert is never silently dropped.
Rule operators include in, nin,
contains, not_contains,
starts_with, ends_with,
exists, not_exists, gt,
gte, lt, lte. You can
match on severity, but also on any other top-level
field your tool sends — environment,
service, region, anything.
The call goes onto a queue
The matched action (call_primary,
call_on_schedule, call_all,
call_project, call_member) resolves to
a list of phone numbers. We write a row to
incoming_requests, enqueue one message per phone,
and return HTTP 202 to your monitoring tool quickly enough that
the round-trip from your monitoring tool’s perspective is
well under a second in normal conditions.
Three brakes apply at this stage:
- Daily org cap. No more than 100 calls per organization per day. Counter resets at midnight UTC.
- Per-phone cooldown. A given phone is not called more than once per 60 seconds, regardless of how many rules resolve to it.
- Per-endpoint suppression. After a successful call, the same endpoint is suppressed for 2 minutes — repeated webhooks return 202 but no calls go out.
These exist so a misbehaving alert source cannot drown you in calls.
The PBX dials over SIP
A queue consumer picks the message up and asks our Asterisk fleet to place the call via the Asterisk REST Interface (ARI). We have five PBX servers — two on Oracle Cloud (EU regions), one on AWS us-east-1, one on GCP us-east1, one on Azure Korea Central — each backed by a different SIP trunk (Zadarma, Twilio, Telnyx, Intertelecom respectively).
A health-aware registry picks a healthy PBX in round-robin
order. If the chosen PBX or its trunk fails to place the call,
we automatically retry on a different PBX with a different
trunk. Up to three retries before the call is logged as
failed.
You pick up (or you do not)
Your phone rings from a CallPing caller-ID number. There is no voice message, no IVR menu, no recorded announcement — the call itself is the alert. You answer, reject, or let it ring. The disposition (answered, no-answer, busy, failed) is reported back to us by Asterisk and logged in your Call Logs page shortly after hangup.
If the call did not get through (carrier reject, voicemail-as-answered ambiguity, etc.) you can see the full ARI status and response in the call detail view.
What is behind the scenes
We run five Asterisk PBX servers across three cloud providers (Oracle, AWS, GCP, Azure) and four SIP trunks (Zadarma, Twilio, Telnyx, Intertelecom). The geographic and provider diversity is the point — if one provider has a bad day, the call retries through a different one.
This is not a “multi-region” marketing line. Most competitors gate that capability behind their Enterprise tier. We ship it on every plan because reliability of delivery is the product.
We do not publish a contractual SLA on the Solo or Team plans at v1.1.0. Our Enterprise tier offers a commercial SLA with service credits — see the security page for the framing and contact us to discuss. Public uptime data is at status.callping.app.
What CallPing does NOT do
We list these explicitly because the right people self-select.
- No AI voice or text-to-speech. We do not read alert text aloud. The call itself is the alert.
- No recorded messages. No announcements, no IVR menus, no “press 1 to acknowledge.”
- No SMS, email, Slack, or chat delivery. Phone calls only. If you need chat acknowledgement, that is roadmap (v1.3 candidate).
- No incident management. No war rooms, no postmortems, no AIOps grouping. We are the alert delivery layer, not the incident-response layer. Mature ITSM platforms do that better than we ever will.
- Not for life-critical or safety-critical systems. We are infrastructure. Phone-call delivery depends on third-party SIP trunks and downstream carriers, any of which can fail. Always have redundant alerting paths appropriate to the criticality of your operations.
- Not a marketing or telemarketing platform. Outbound calls must be to numbers you own or have consent to call (see our Acceptable Use Policy). Emergency, premium-rate, toll-free, and short codes are blocked at intake in 30+ countries.
Ready to try it
Five minutes from signup to a ringing phone. Card required at signup. No charge for 14 days. Cancel any time from your billing page before day 14 to avoid the charge.
Card required at signup. No charge for 14 days. Cancel any time before day 14 to avoid the charge. By starting a trial, you agree to our Terms of Service, Privacy Policy, and Acceptable Use Policy — including your responsibility to obtain consent from every recipient you configure CallPing to call.