Five things a webhook can do once it reaches CallPing.

A webhook rarely carries just a severity level. It carries a message, an environment, a service name, a region, a customer tier — anything the sending tool decided to include. CallPing’s routing rules can match on any of it. Rules run in order, top to bottom, first match wins: severity in ["critical","major"], sure, but also message contains "OOM" or environment starts_with "prod-eu" or service exists. Twelve operators cover equality, membership, substring matching, existence checks, and numeric comparison — in, nin, contains, not_contains, starts_with, ends_with, exists, not_exists, gt, gte, lt, lte.

Matched rules don’t just decide whether to call — they decide who. A rule can ring the primary phone, everyone on the roster, whoever’s on shift right now, a named Project (a subset of your team — “database,” “payments,” “support”), or one specific person by name regardless of what shift they’re on. Projects fall back to the primary phone if the project has no active members, so a routing rule never silently points at an empty room.

And when nothing matches — the alert your tool sent doesn’t fit any rule you wrote — the scenario still has to do something. That “something” used to be hardcoded to ring the primary phone, which for a team meant an arbitrary person could get called even if they were off shift. It’s now a per-scenario setting: ring the on-call schedule, ring everyone, or ring the primary phone, your choice, picked in the scenario editor under “When no rule matches.” Solo scenarios skip the schedule option entirely — there’s no roster to check against.

A routing rule can carry an escalation chain: up to 10 steps, each one a target (the primary phone, everyone, the on-call schedule, a Project, or a named member) and a delay before it fires — anywhere from immediate to 15 minutes. If the first call goes unanswered, the next step in the chain gets enqueued on schedule. No manual retriggering, no separate on-call tool bolted on the side.

The harder problem than “ring again” is “know when to stop.” CallPing treats an answer, an active decline, and a busy/engaged line the same way: all three close out the alert immediately and cancel every other phone still ringing for it, so a five-person fan-out doesn’t turn into four more phones ringing after someone already picked up or the line was engaged. Only a genuine no-answer advances the chain. The distinction matters in practice: a busy signal or an actively declined call means the call reached a real phone, which is a different signal than one that simply never got picked up.

For teams that would rather not ring everyone at once, a round-robin dial strategy dials on-call members one at a time in fair rotation instead of all simultaneously — spreads the load across the roster and still stops as soon as someone answers or declines.

People belong to more than one organization in real life — a contractor working two clients, an engineer who moved teams but still gets pulled into the old one’s incidents. CallPing’s multi-org membership lets one login hold multiple orgs at once, with an org switcher to move between them; no separate accounts, no separate passwords to remember.

Ownership isn’t pinned to a single founder account either — an org can have any number of owners, so losing access to one person’s login doesn’t mean losing control of the org. Time-based one-time password (TOTP) two-factor authentication is available to lock down login, and sensitive actions — changing a member’s role, rotating an API key, deleting a project — require a fresh re-authentication even within an already-logged-in session, so a stolen session token alone isn’t enough to do damage.

Every meaningful account action — who turned a phone on or off, who changed a member’s role, who deleted what — lands in a 90-day audit log per org. It’s there so “who did that and when” has an answer that isn’t “check everyone’s memory.”