This week I found out my walking game had been doing nothing for weeks.
It was live on the App Store. You could download it, open it and tap around. But nothing worked, because the service behind it had been paused. No alert went off. No email arrived. No user wrote in. It just sat there, looking fine and doing nothing.
I fixed it the same night. What stuck with me is that I had no way of knowing. And it wasn’t the first time.
Quiet failures are the normal kind
When you build with AI, you test while you build. Everything works, because you’re watching. The problem is what happens when you stop watching. Here are some of the ways my projects have broken with nobody noticing:
The alert that watched the wrong thing. On an earlier side project, I had an alert that checked whether the server was on. The server was on. The thing it was supposed to run had stopped, and it stayed dead for three weeks before I noticed.
The key that expired. An access key that all my tools depended on quietly reached its expiry date. Every tool that touched my database stopped working at the same moment, with an error that said nothing about why.
The room nobody could talk in. In the community app I’m building, a group chat had 21 members and had never had a single message. That wasn’t a quiet group. It was a bug: one rule let people see the chat, and a different rule stopped them posting in it. A message looked like it sent, then disappeared. I only found out because someone told a friend, who told me.
The server I’d stopped but was still paying for. Stopping a server isn’t the same as no longer being billed for it. The bill doesn’t send an alert either. It just arrives.
None of these crashed. Crashes are easy: something yells. These were silent, and that’s what makes them expensive.
Why AI-built apps fail quietly
When you ask an AI to build a feature, it builds the feature. It doesn’t build the part that tells you when the feature stops working, unless you ask. And you don’t ask, because while you’re building, you’re the monitoring. You’re right there, looking at it.
Then you launch, you look away, and the only remaining alarm is a user who cares enough to complain. Most won’t. They’ll just leave.
Five habits so you hear about it first
1. Check what a person does, not whether the machine is on
“Is the server running?” is the wrong question. “Can someone do the main thing right now?” is the right one. For my game, that means a small daily check that does what a real player’s app does. If it fails, I hear about it the next morning instead of weeks later.
How would I find out right now if this app stopped working for users? Suggest a simple daily check that performs a real user action (not just “is the server on”) and tell me where its alerts would go.
2. Make sure the alert actually reaches you
An alert that goes to an inbox you never open isn’t an alert. Break something on purpose in a test version and watch for the message. If you never get it, you don’t have monitoring. You have a setting.
3. List everything that expires
Keys, certificates, domains, free trials, free-plan limits. Each has a date, and AI won’t remind you. Put them on a calendar the day you create them.
List every key, token, certificate, domain and subscription this project depends on, what happens when each one expires or lapses, and its date if you can find it.
4. Find out what your free plans do when nobody’s looking
Some services pause projects that haven’t had activity for a while. Supabase, for example, pauses free projects after 7 days of low activity. That’s a fair deal for a free plan. You just need to know it before your users do.
5. Read the silence
Zero is a number worth questioning. Zero messages in a busy group, zero sign-ups after a launch, zero errors in a week. Sometimes zero is good news. Sometimes it means the thing that would have produced the number is broken. Ask which.
Look at the main activity in this app: sign-ups, posts, purchases. If any of them dropped to zero, how would I notice, and what’s the most likely silent cause?
The design lesson
Monitoring sounds like an engineering topic, but the question underneath it is a design question: what does a person experience when this breaks, and who finds out first? If the answer is “the user, and nobody else,” that’s a product decision, even if nobody meant to make it.
Every one of these failures taught me to ask that question before launch instead of after. It costs almost nothing to ask early, and quite a lot to find out late.
Want to check your own app? “Knowing when it breaks” is item 10 of the Vibe Coding Checklist. Its free Fix Kit has a prompt to set up a real check, and a way to confirm the alert actually reaches you.
Stuck on a fix? I do a few 1:1 sessions where you share your screen and I teach you how to check and fix it yourself.