The 3am problem
It is 3:14am. Stripe sent a webhook 18 minutes ago saying our checkout endpoint is failing. Datadog paged Slack. Slack pinged a watch. The watch is on Do Not Disturb because the engineer went to bed at midnight. By 6:30am there are 41 angry support tickets and a refund hole that ate the morning.
This is the canonical on-call horror story, and it is not a story about Slack being broken. Slack worked. The watch worked. The engineer’s DND worked. Everything worked. The problem is that chat is silent at night by design, because if it were not, every minor warning would wake everyone, and within a week the whole team would have suppressed it harder than they already do.
You cannot have it both ways. Either chat is loud enough to wake people and your sleep gets demolished by warnings, or it is quiet enough not to demolish your sleep and the actual fires never wake you.
The conventional fix is “page differently.” Use a paging tool that calls instead of pings. Many of the established tools require minimum seat counts at their entry tier — PagerDuty's cheapest paid plan, at the time we wrote this post (April 2026), is around $21 per user per month with a five-seat minimum, which works out to roughly $105/month even if you have only one on-call engineer. Verify current pricing on the vendor’s own site before you decide. Or pay an engineer’s weekend to wire up a generic programmable-voice provider plus a Lambda — and an engineer’s weekend a year, every year, to maintain it.
We thought there was room for a smaller, sharper tool that did one of those things — the call — and only that.
Why chat does not wake people
Chat tools are built around the assumption that a human is in front of a screen. Notifications stack up; you check them when you get back to your desk. The model is “leave a note for later.” Most of the time, that is exactly what you want. You do not want every Slack mention to interrupt you in the middle of a meeting.
But the same property that makes chat livable during the day makes it useless at night. The notification is queued, not interrupting. The watch buzzes once and goes still. The phone screen lights up for two seconds and goes dark. The engineer rolls over.
Even when push notifications work — and they often do not, because watches are silenced, phones are face-down, OS battery savers throttle background sync, the kid was sick and Slack got muted to “Important only” — the engineer can ignore them. Chat is opt-in attention. The whole UX is built on the premise that you decide when to look.
A phone call is not opt-in. The phone rings. It rings on the lock screen. It rings through Bluetooth speakers. On many modern phones, a real voice call from an allowed contact can be configured to ring through Do Not Disturb. It is not subtle. It is the one channel that was designed, from telecom day one, to interrupt.
That is the entire premise of CallPing.
Why phone calls
We took a strong product opinion: that a ringing phone is the most reliable way to wake a sleeping operator at 3am, more so than SMS, push notifications, email, or chat. We do not have a peer-reviewed study to back this — the operator-experience evidence is anecdotal — but it is the opinion baked into every product decision below. If you disagree, this is not the right tool for you. If you have ever silenced your watch and missed a 3am page, you already know.
Other paging tools that existed when we started building (PagerDuty, Opsgenie, Squadcast, ilert, SIGNL4, Spike.sh, among others) figured this out long before us; we are not claiming to have invented anything. What we changed is the bundle.
Most paging tools sell phone calls as part of a larger product — incident management, postmortems, AIOps, ChatOps integrations, mobile apps, status pages, war rooms. If you want phone calls, you pay for the bundle. We took the bundle apart.
CallPing is webhook in, phone call out. That is the entire product surface. No incident management. No AIOps. No status-page-tied-to-incidents. No postmortems. No war rooms. No mobile app. The price reflects that. The interface reflects that. The cognitive load reflects that.
If you want all the other things — incident management, AIOps, status pages tied into incidents, the full ITSM surface — there are mature platforms for that. We will not try to convince you we are one of them; we are not.
What we deliberately do not do
The product opinions baked into CallPing, listed without sales fluff:
No AI voice. When the call rings, there is no voice on the other end reading “Critical alert: Stripe checkout endpoint returning 5xx.” There is no voice. The call itself is the alert. You answer to confirm; you check the source for details. We could ship text-to-speech in an afternoon. We have chosen not to. The reason: the moment you have a recorded voice, alert authors start writing for it, and within six months you have alert authors carefully tuning a recorded message instead of writing a clear webhook payload. The message belongs in your monitoring tool, not in our call.
No recorded messages. Same reason. No “Press 1 to acknowledge.” No menu trees. The call is the signal.
No SMS, email, Slack, or chat delivery. Phone calls only. Slack acknowledgement is on the roadmap (v1.3 candidate) because it is genuinely useful for noisy daytime traffic, but it will never replace the call as the wake-up channel. SMS we will likely never ship — adding it implies a wake-up channel parity with calls that we do not believe exists.
No incident management. We do not run an incident lifecycle. We do not create war-room channels. We do not run postmortems. We do not draft status-page updates. PagerDuty does all of those well; integrating into PagerDuty’s stack is fine, but we are not going to compete head-on with a mature ITSM platform.
No mobile app. This is the most contrarian. Every competitor markets a mobile app. We do not have one. The reason: the phone call IS the mobile experience. Adding an app would mean adding a second alerting channel, which means inheriting all the failure modes of push notifications. The call already works.
Not for life-critical or safety-critical systems. This one is not a product opinion; it is operator humility. Our calls go through third-party SIP trunks and downstream telephone carriers. Any of those can fail. We have built the system to retry across five PBXes and four trunks, but no amount of redundancy at our layer fixes a downstream carrier outage. Always have redundant alerting paths appropriate to the criticality of your operations.
Do not use CallPing as the only alerting channel for life-critical or safety-critical systems. If a missed page ends with a hospital incident or a casualty, do not put us on the only path to it.
Closing
If your monitoring tool can POST a webhook and you have a number a phone can dial, CallPing will ring it. That is the entire pitch.
If you are running a small rotation and the per-seat minimums on the larger paging tools have been quietly burning your CFO’s patience, start a 14-day trial — card required at signup, no charge for 14 days, cancel any time before day 14 to avoid the charge.
We are smaller than the incumbents and we are not pretending otherwise. We do one thing well, we charge for it once, and we do not ship the things we cannot do well yet.
— The CallPing team