Skip to main content
🩺

Monitoring Checklist for AI-Built Apps

Error tracking and observability

When you vibe code monitoring with tools like Cursor, Lovable, Bolt, v0, or Claude Code, the generated code often works in development but misses critical production requirements. This checklist helps you catch what AI missed before you ship.

Danger Zone

high risk

The worst thing that can happen is already happening — you just don't know it yet

Your app looks fine on your laptop. But out in the real world, someone on slow WiFi in Brazil is staring at a loading spinner that never ends. Someone else just hit an error that crashed their checkout flow. A third person's data isn't saving. None of them will tell you — they'll just leave. Monitoring isn't about collecting data, it's about knowing which fires to put out first.

Failure scenario

Your app launches and gets featured somewhere. Traffic spikes 10x overnight. Your database starts timing out but you don't notice because everything looks fine when you test it. By morning you have 200 frustrated tweets, a 2-star rating forming, and no idea which part of your system is actually broken. You spend hours adding logging and refresh buttons trying to figure it out while more users bounce.

Common mistakes

  • Only logging errors on your own computer, not from real users in production
  • Logging so much that finding the actual problem is like searching for a needle in a haystack
  • No way to know if the site is down except waiting for someone to email you
  • Error messages that say "something went wrong" with no context about what or where
  • Not tracking which errors affect the most users — treating rare glitches the same as showstoppers

Time to break: Immediately after launch when real traffic patterns hit

How are you building this?

Showing what to check when using a managed service

Audit Prompts

Copy these into your AI coding assistant to check your implementation.

Are you actually seeing the errors users hit?
reliability
Check our error tracking setup (Sentry, Highlight, etc). Are errors from production (real users) being captured, or just errors on our development machines? When an error happens, does it include enough context — which user, what page, what they were doing? Are errors grouped so we can see patterns, or is each one treated as a new issue? Can we see a replay of what the user did leading up to the error?

If you only see errors on your laptop, you're missing 99% of what's breaking for real users. And without context, an error message is just a riddle.

Would you know if your site went down right now?
reliability
Check our uptime monitoring (BetterStack, Pingdom, UptimeRobot, etc). Is it checking our site every few minutes from multiple locations? Does it test the actual important pages (login, checkout, dashboard) or just the homepage? When it detects downtime, does someone get a text or call, not just an email? Is there a status page where users can check if it's just them or everyone?

Users expect apps to work 24/7. If your site goes down at 2am and you don't find out until morning, that's hours of lost trust and revenue.

Can you tell which problems matter most?
performance
Look at how our monitoring tool prioritizes issues. Can we see which errors affect the most users versus rare edge cases? Are we tracking key user actions (signup, checkout, data save) as separate metrics so we know if something critical breaks? Do we get alerts for the big stuff but not for every tiny thing?

Not all errors are created equal. One bug affecting checkout for everyone is more urgent than a typo on a settings page.

Are you tracking the user experience, not just errors?
performance
Check if we're monitoring performance beyond just crashes. Are we tracking how long pages take to load for real users? Do we see where users get stuck or frustrated? Can we identify slow database queries or API calls? Are we tracking these metrics separately for different browsers, devices, and locations?

Most problems aren't crashes — they're pages that load too slowly or buttons that don't respond fast enough. Users leave before they even see an error.

Checklist

0/10 completed

Smart Move

Use a service

Basic error logging is easy to build. But connecting errors to specific users, replaying their session to see what happened, grouping similar issues, and getting alerted when something spikes — that's where DIY falls apart. A monitoring service pays for itself the first time it catches a critical bug before you lose a customer.

Sentry

Industry standard error tracking with performance monitoring — see exactly what broke and why

5,000 errors per month free

BetterStack

Uptime monitoring with incident management — get a phone call when your site goes down

1 site monitored every 3 minutes free

Highlight.io

Session replay and error tracking in one — watch a video of what users did before hitting an error

500 sessions per month free

Tradeoffs

Free tiers are generous but fill up fast if you have bugs or traffic. You might need to filter out noisy errors or upgrade sooner than expected. The alternative is finding out about problems from angry users.

Did you know?

The average web app error goes undetected for 4.7 hours when there's no monitoring, and 53% of users will abandon a site that takes more than 3 seconds to load — often without ever reporting a problem.

Source: Google Web Vitals Research & Raygun Error Monitoring Survey 2024

Related Checks

📊Analytics

Track what users do

⚙️Background Tasks

Process things without making users wait

⚡Live Updates

Real-time sync without refreshing