Building Apps with AILesson 80 of 87

Contents

Building Apps with AI

Lesson 80 of 87. Sign in to keep your place.

Module 9 · What it costs, running it, and where this stops

Knowing it broke before users tell you

8 min read

Three watchers, because each is blind to the othersSomething threwNothing threwThe site answersError trackera route crashedReport buttonworked, but wrongNothing answersUptime monitorthe process is goneUptime monitorDNS or the hostThe bottom row is one watcher twice, and that is the point: nothing answering looks identical whetheror not your code threw. The top right is the expensive one, because it runs quietly for weeks.
The bottom row is one watcher twice, and that is the point: nothing answering looks identical whether or not your code threw. The top right is the expensive one, because it runs quietly for weeks.

Figure

Three kinds of broken

The deploy lesson said to find the logs and get told about errors. This lesson is about what “told” has to cover, because there are three different ways an app is broken and each needs a different watcher.

It throws. A route crashes, a page fails to render, a promise rejects. Something in the code raised an error.

It is down. Nothing answers, or the answer is a host’s error page. The code may be fine; the process, the database or the DNS is not.

It is wrong. Every request succeeds and the result is incorrect. The date is off by one, the total is wrong, the email went to the wrong person. No error, no outage, and the most expensive of the three because it runs quietly for weeks.

What throws: error tracking

Sentry’s free tier covers a few thousand events a month, which is more than a small app should produce. Alternatives with free tiers exist (LaunchDarkly’s observability tools, which took over Highlight in 2025, and GlitchTip, which also runs on your own server) and every host has a basic error log. Whichever, the setup is a few lines and three settings that matter.

Upload source maps at build time, so that a stack trace names your file and line rather than a position in a minified bundle. Without them, the tracker tells you something failed at column 48,213 of main.js.

Attach the request id and the user’s id (the id, never the email) to every event, so that a report can be joined to a person’s complaint.

Check the scrubbing. Trackers can send request bodies and headers by default; a body containing a note’s full text is then in a third party’s storage. Sentry already strips authorisation headers, cookies and fields named like passwords or tokens, and keeps server-side scrubbing on by default; leave it on, confirm the same on any other tracker, and add rules for your own sensitive fields, such as a note’s text.

Then the alert: a new type of error, first seen, emails you. Not every error: a known flaky one at 3am is noise you will learn to ignore, and then you will ignore the real one. Alert on new and on rate, and look at the rest weekly.

What is down: the monitor

The health route from the shipping block, pinged every minute or five by a free service, with an alert when it fails twice in a row. Two in a row, not one: a single failed ping is usually the monitor’s network, and an alert that fires on it teaches you to ignore alerts.

Make the health route check what matters: a trivial query against the database, so that a paused database (the previous lesson) reads as down rather than as up-with-errors. Return the commit sha, so that the monitor’s history doubles as a record of which version was live when.

What is wrong: the report button

Nothing automatic catches the wrong date. A person does, and the question is whether they can tell you in a way you can act on. A “report a problem” link on every page, opening a small form that captures, with consent, the page URL, the browser, the last few console messages and a screenshot, and sends them with the user’s id to a table you read. Twenty lines of client code and one route. Addaly’s own site carries one on every page for this reason.

The alternative is an email address in the footer, which the deploy lesson suggested and which is better than nothing and worse than a form: the email says “it didn’t work” and the form says which page, which browser, and what the console printed.

Read the reports. A report table nobody looks at is an apology form.

The one metric worth a glance

Beyond errors and uptime, one number: how many of the key action succeeded today. Bookings created, notes saved, whatever the app is for. A count per day in a simple query, and a look at it each morning. A drop with no errors is the wrong-answer bug from the check above, or a broken button, or a change in who is visiting. It is the cheapest early warning there is, and the generated app has no such number until you ask.

What not to build yet

Dashboards with twelve charts, distributed tracing, log aggregation across services, alerting hierarchies. The cloud course covers them for the day the app has a team. A single-person app needs an error tracker with scrubbing and source maps, a two-strike uptime ping, a report button, and one daily number. That set costs nothing and it is the difference between learning about a problem from a tool and learning about it from a tweet.

Every lesson here is open. Your progress is recorded once you pass the Building with AI exam.

Check your understanding

An app has error tracking with alerts, and an uptime monitor on its health route. Users report that bookings made on the last day of any month are saved with the wrong date. Neither tool ever alerted. Why not?

Pick the one you would defend. Your answer stays private.

Next lesson · 8 minThe first user complaint

Stuck on something?Ask Beatriz, your AI tutor

Previous lesson: The free tiers, and exactly where they end

How to cite: Addaly (2026) ‘Knowing it broke before users tell you’, in Building Apps with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-apps-with-ai/knowing-it-broke-before-users-tell-you (Accessed: 13 October 2026).