Your app broke and a customer told you before you knew.

It usually goes like this. Someone writes to say the checkout spins and never finishes. You try it and they are right. Then you start wondering how long it has been broken and how many people hit the same thing and left without writing. The person who emailed is the one who cared enough to tell you, and most people who meet a broken page close the tab.

If a customer is the one who tells you the app is broken, you found out too late. By then the failure has already cost you whatever those visitors were about to do, and you are working backwards from a single complaint with no idea when it began.

Apps built with AI tools end up here often, for a plain reason. You asked for features, and the tool built features. Nobody asked for a way to hear about trouble, so none was built. The app works while you are testing it, and after launch the only people watching it are the customers.

A log is a running list of what the app did and what went wrong, kept by your host, your database or the app itself. It is useful once you already know there is a problem, because it tells you what happened and when. Its weakness is that it sits there until a person opens it. If nobody opens it, an error written at nine in the morning is still unread at five.

An alert is a message sent to a person at the moment something goes wrong: a text, an email, a notification in a chat tool you already keep open. It carries enough to act on, meaning what failed, when, and where to look. The log is the record and the alert is the tap on the shoulder, and a launched product needs both.

Most AI-built apps we see have some logging, because hosting platforms commonly keep logs without being asked. Very few have a single alert. That gap is why the founder learns about a failure from a customer when the evidence was sitting in a log the whole time.

An alert only works while the person receiving it still reads it. The fastest way to lose that is to send messages that need no action. After a week of texts about things that fixed themselves, you start swiping them away, and the one that matters gets swiped with the rest.

So hold each alert to a test: when it arrives, is there something you would do in the next hour? If the answer is no, move it to the log. If the answer is sometimes, tighten the condition until it is yes. A single failed sign-in is one person mistyping a password. Many failed sign-ins in a few minutes is your login being down, and that is the one to send.

Group repeats as well. If the payment step is broken, you need one message saying so and perhaps a reminder later while it stays broken. Forty messages, one per failed attempt, tell you nothing the first did not.

You do not need to read code to get the first few alerts in place. There are two kinds, and they cover different failures. The first watches from outside: a service visits your site on a schedule, the way a customer would, and messages you if the page does not answer. That catches the whole app being down, which the app cannot report about itself.

The second kind lives inside the app. At each of the steps on your alert list, the code notices its own failure and sends a message. Error tracking services exist for this, and many hosting platforms and payment providers can also notify you about failures on their side. Check what the accounts you already have will send before adding anything new.

Your AI tool can write the inside kind if you ask for it one step at a time and describe it the way you would to a person. For example: when a payment fails for a reason other than the customer's card being declined, send me an email that says which step failed and when, and do not send more than one for the same problem within an hour. Then ask the tool to show you where that message is sent from, so you know it exists.

Keep the secret keys for any alerting service out of the code the browser receives, the same as any other key. If you are unsure where your keys ended up after moving the app to a live address, our guide on apps that work locally and fail in production covers that.

An alert you have never seen arrive is a guess. The code that sends it can be wrong like any other code: pointed at an old phone number, waiting on a condition that never happens, or relying on the very service whose failure it is meant to report. The only way to know is to break the thing on purpose and watch for the message.

Do this on a test copy of the app if you have one. If you only have the live app, pick a quiet hour, use your own account and undo each change straight after. Write down what you broke, whether the message came, how long it took and whether it told you enough to act.

A founder can usually get the outside check and one or two inside alerts working alone. Get help when the alerts fire and you cannot tell from them what is wrong, when the same failure keeps coming back after each repair, or when the tests above show an alert that never arrives and the AI tool cannot explain why. Help is also worth having when money moves through the app and you cannot say with confidence what happens on a failed payment.

Our Diagnostic is a fixed-price written plan, with the fee credited to the build if you go ahead with us. For this problem we read the code and the accounts it depends on, list the steps where a failure would cost a customer, note which of them report anything today, and set out what to add in order. The work is done in your accounts, and your repo and accounts stay yours.