In September 2026 a founder posted on Reddit about a 94-minute outage of his AI voice product during a Saturday service.
A founder posted on Reddit this week about an AI voice product his team built for restaurants and bars. He’s a front end developer and built the backend with AI. His two co-founders handle sales and distribution.
Venues started testing it live. Then on a Saturday evening their voice provider went down for 94 minutes. He only found out because he made a test call by chance. Nothing alerted him and calls didn’t fall back to the venue.
He thinks they got lucky because no business calls were lost, and he’s possibly right. By 8.30 on a Saturday most venues are mid-service and the phone’s usually quiet. The operator won’t see it that way. They’ll see an outage on their busiest night and ask about compensation for bookings they might have lost.
His co-founders don’t trust the tech any more, and one is ready to walk.
The code might be fragile, but that’s not what failed on Saturday. Nobody had built monitoring, alerting or a fallback. AI tools build what you ask for. They won’t ask what happens when a provider you rely on stops responding. AI means you can build a working product without ever having run one in production. I learned to ask that question the hard way running a reservation platform. A database running slow, web servers that couldn’t handle the traffic, a third party going down. The list goes on.
The developer asked what the bare minimum is before taking on another client. For a hospitality phone product I’d want four things in place.
First, monitoring that works when it’s quiet as well as when it’s busy. Watch live traffic for calls where the AI doesn’t respond. When there’s no traffic, run test calls that actually generate speech and check it comes back. Checking the API responds isn’t enough. According to the post, the provider didn’t spot its own outage.
Second, an alert that wakes someone up. By phone, not email or Slack.
Third, a way to send calls to the venue’s own number when the AI isn’t working. Twilio, for example, lets you set a fallback that takes over when the primary handler fails. That won’t catch a silent failure, where the call connects and nothing speaks, so the product needs to check for that during the call too. Of the four, this is the one the operator cares about.
Fourth, every venue should know what happens during an outage before one happens, including what you will and won’t compensate. When one does happen, they should hear it from you first.
A second voice provider is worth adding later. Routing calls back to the venue is the priority for this week.
On the co-founders. If you can’t read the codebase, you judge it by what breaks, so that outage becomes the whole story. Telling them you’ll be more careful won’t change that. Write down what can fail, what happens when it does, and what you’ve fixed. That gives them something to check.