You make one. Every hour.
Testing a web app is a solved problem. Render the page, click the button, assert the thing. Testing a voice agent, though, is a different story. One call passes through STT, an LLM, TTS, and a real telecom network, live, in sequence. Any link in that chain can quietly break, and the product becomes an awkward silence on a phone line.
Unit tests don’t catch a carrier misbehaving in the middle of the night. Status pages don’t either; every dependency can be “up” while calls are broken end to end.
So we built Canary!
Coal miners kept canaries to notice bad air before it noticed them. Ours makes phone calls. Every hour, a robot caller dials our production stack, over real phone lines, and checks that everything works the way a real caller would experience it.
We didn’t start by “covering everything”. We started from our clients instead. The first canaries were built around real client flows, the same journeys their callers take every day. If those work, the platform works. From there, Canary grew to cover the platform’s most vital paths. And it doesn’t just check that a call happened: it checks the whole journey, that the agent spoke, the conversation went where it should, and the data landed where it was supposed to, right down to the record in a client’s CRM.
The same machinery scales up, too. Because Canary already knows how to be a caller, it can just as easily be many callers at once. That turns the pipeline into our load-testing rig: waves of concurrent calls against the platform, so we find any capacity limits in a drill we run, not on the day a client launches a big campaign.
And when something breaks, we don’t find out from a client. Canary alerts us and someone gets paged before anyone else notices.
Voice AI demos are easy. What our clients get, though, is the guarantee that the call actually gets answered, correctly, at 4am on a Friday. Canary is how we know. It sings every hour, and the whole point is that nobody thinks about it until it stops.
