Webhook to phone call, end to end.

Severity is read from whichever of these field names your payload actually uses — severity, status, level, priority, alert_type, alertLevel, alert_level — first one found wins. Common values (p1, critical, high, error, warning, info, resolved, and others) normalize to one of critical / major / minor / info, so you don’t have to rename your tool’s payload to match ours.

The endpoint is linked to a Scenario, which holds an ordered list of routing rules evaluated top to bottom. The first rule whose condition matches wins. Rules aren’t limited to severity — twelve operators (in, nin, contains, not_contains, starts_with, ends_with, exists, not_exists, gt, gte, lt, lte) let a rule match on any field in your payload: the message text, an environment tag, a service name, whatever your tool sends.

If nothing matches, the scenario’s configurable catch-all default action fires — ring the on-call schedule, ring everyone, or ring the primary phone, set per scenario. An alert is never silently dropped for lack of a matching rule. One honest exception: if that action is “ring the on-call schedule” (or a Project) and nobody happens to be on shift at that moment, CallPing doesn’t fall back to ringing someone off-rotation — it rings nobody and fires an operator alert flagging the coverage gap, loudly, instead of quietly paging the wrong person.

The matched action resolves to a list of phone numbers. We write a row recording the incoming request, enqueue one message per phone, and return HTTP 202 to your monitoring tool — the actual dialing happens asynchronously from here, so your webhook sender isn’t held open waiting on a phone call to place.

Before a message is dequeued and dialed, the safety brakes below apply (daily cap, per-phone cooldown, phone-number blocking). None of them require configuration.

CallPing runs on 5 registered Asterisk PBX servers across 4 cloud providers (Oracle Cloud, AWS, Google Cloud, Azure) — but only 3 of the 5 currently carry a live SIP trunk and can actually place a call; the other 2 are held in reserve as standby capacity. Those 3 call-capable servers span 2 providers (two on Oracle Cloud, one on Google Cloud) and 5 SIP trunks between them. A health-aware registry selects among the call-capable PBXes in round-robin order, filtered first by which trunks actually serve the destination country — a UK number and a US number don’t necessarily route through the same trunk.

If the selected PBX or trunk fails to place the call, it retries automatically on a different PBX through a different trunk — up to three attempts before the call is logged as failed. That retry can cross a cloud-provider boundary, so a single trunk having a bad day doesn’t end the attempt — though honestly, two of the three call-capable servers currently sit on the same cloud provider and in the same city (Frankfurt), so a provider-wide or metro-wide outage there could still take both of them out at once.

A queue consumer picks the message up and asks Asterisk to originate the call through its REST Interface (ARI). Answering-machine detection In progress is being built to run on the call and distinguish a human answering from a voicemail or interactive voice response (IVR) pickup; once it ships, a call that connects to voicemail won’t get treated as delivered. Today, a voicemail pickup is logged the same as a human answer.

There is no voice on the line reading your alert text aloud, no recorded announcement, no “press 1 to acknowledge.” The call itself is the alert.

When the call ends, Asterisk posts the outcome to our disposition endpoint, matched back to the original call by its channel ID. Every call resolves to one of five terminal statuses — answered, busy, no-answer, canceled, or failed — derived from the actual SIP cause code, not a generic “call ended” flag. (An active decline isn’t a separate status — it’s recorded as the reason on a busy disposition, not a distinct outcome.)

An answer, an active decline, or a busy/engaged signal that actually reached a phone all stop the entire alert immediately: any other phone still ringing for the same alert is cancelled. Only a genuine no-answer advances the alert (see Step 7).

If the matched rule carried an escalation chain and the disposition was a genuine no-answer, the next step in the chain — up to 10 steps total, each with its own delay of up to 15 minutes — gets enqueued, targeting the primary phone, everyone, the on-call schedule, a Project, or one named person. If there’s no chain configured, the alert simply ends at the first disposition.

Full detail on every attempt — the raw ARI status, the SIP cause code, timestamps — is visible in your Call Logs.