What to Do When Your AI-Built App Breaks in Production

Your AI-built app breaks in production and the instinct is to start changing code. Don't. The fix that actually works follows a fixed order: confirm the deploy itself is fine, confirm environment variables are set on the platform, reproduce the exact failing request, read the real runtime error and its stack trace, check what changed since the last working deploy, then hand the precise error to your AI coding agent with full context. Skipping steps is how a five minute fix turns into a two hour session where you and the AI are both guessing.

The triage order: what to check first, second, third

Most “app is broken” advice stops at “check the logs.” That's not wrong, it's incomplete. Logs tell you what happened. They don't tell you what changed, or why it only happens in production and not on your machine. Work through these in order, before you touch a single line of code.

1. Check the deploy status, not the app

2. Check environment variables and secrets on the platform itself

3. Reproduce the exact failing request

4. Read the full runtime error and stack trace, not the summary

5. Check what changed since the last working deploy

6. Hand the real error to your AI agent with full context

7. Verify the fix against the same reproduction case before it goes live again

1. Confirm the deploy actually shipped what you think it shipped

Before you assume your code is broken, check whether the deployment finished. A build that fails partway through can leave a platform serving the previous version, or in some setups nothing at all. Open the deploy log in your hosting dashboard first: build status, build duration, and whether it matches the commit you expect. If the build failed, the bug isn't in your app logic, it's in the deploy, and no amount of prompting an AI agent to “fix the error” will touch it.

2. Check environment variables and secrets where the app actually runs

The single most common reason an app works on your laptop and crashes the moment it's public is a missing or mistyped environment variable. Your .env file never leaves your machine, so every variable your app reads at runtime, database URLs, API keys, auth secrets, has to be set again, by hand, in your hosting platform's dashboard. Miss one and the app either crashes on startup or fails only on the one code path that touches it, which is exactly why it can look fine right up until a real user hits checkout or login. This is common enough that it's worth checking before you open your code editor, not after.

3. Reproduce the exact failing request

“It's broken” is a mood, not a bug report. Before doing anything else, get to one specific action you can trigger on demand: this URL, this button, this form submission. While you're at it, note whether the failure is consistent (same request, same error, every time) or intermittent (works, then doesn't). Intermittent usually points to a timeout, a rate limit, or a race condition, not a straightforward code bug. A concrete reproduction case is also the single biggest factor in whether your AI agent's fix is accurate or a guess, which matters a lot in the next step.

4. Read the actual runtime error, top to bottom

Not the toast notification. Not “something went wrong.” The real server-side error and its stack trace. Where you find it depends on where the app runs, and how long it stays there depends on your plan. On Vercel, for example, runtime logs live under the Logs tab in the project dashboard, and retention scales with plan: Hobby keeps about an hour, Pro keeps a day, Enterprise keeps three days, and teams with Observability Plus get 30 days. If you're trying to debug something that happened yesterday on a Hobby plan, that log is already gone, which is its own argument for checking logs immediately instead of after you've already tried three unrelated fixes.

5. Check what changed since the last working deploy

If it worked yesterday and doesn't today, something changed: your code, a dependency, an environment variable, or an upstream API you don't control. Diff your current commit against the last known-good deploy. Check your lockfile too. Dependency version bumps that happen automatically on a fresh install are a frequent source of “I didn't change anything” breakage, because technically you didn't, npm or your platform's build step did.

How to hand the error back to your AI agent so the fix is right the first time

This is where most AI-built-app debugging goes sideways. You paste “checkout is broken, please fix it” into your coding agent. The agent can't see your production logs, so it guesses, rewrites a function that was working fine, and now there are two bugs instead of one. The fix is to give the agent what a competent human engineer would want on a bug ticket: the exact error, where it happened, what changed, and the difference between the environment that works and the one that doesn't.

Here's the difference in practice.

BAD PROMPT:
the checkout page is broken now, here's a screenshot, please fix it

GOOD PROMPT:
Checkout returns a 500 in production after deploying commit 3f2a1c9. It works locally.

Runtime log from production:
TypeError: Cannot read properties of undefined (reading 'total')
at calculateTax (api/checkout.js:42:18)
at handler (api/checkout.js:15:9)

checkout.js itself didn't change in this deploy, but api/cart.js was
refactored to use a new getCart() function.

Here is api/checkout.js lines 35-50: [paste]
Here is the new getCart() in api/cart.js: [paste]

What's different between local and production that would make
cart.total undefined only in prod?

A report that gets a working fix on the first try includes:

• The exact error text and stack trace, copied, not summarized

• The file and line number the stack trace actually points to

• What changed in the last deploy: commit, dependency update, or config change

• Whether it fails in production only, locally only, or both

• The real code around the failure, not a description of it

If your coding agent can read your repository directly, point it at the specific file and function instead of pasting code by hand. That removes one more place for the wrong version of a file to end up in the conversation. Our guide to debugging AI-generated code goes further into isolating the actual failing function before you ask for a fix.

7. Verify the fix in isolation before it hits real traffic again

Test the fix against the exact reproduction case from step three, ideally in a preview deploy or staging environment rather than pushing straight back to production. If the original break was caused by a difference between local and production environments, a fix that only gets tested locally can pass and then fail again in production for the same underlying reason. This is also a good moment to check the fix didn't quietly touch something else, the same review pass worth doing before you ship any AI-generated code.

Why AI-built apps break like this more often

AI coding agents are good at producing code that handles the case you described and less reliable at anticipating the cases you didn't: what happens when an API key is missing, what happens when a network call times out, what happens when a database query returns nothing. That gap is a big part of why AI writes code that doesn't work in the first place, and it shows up exactly when you move from “it works on my machine” to real production traffic. That's not a reason to avoid building an app with AI, it's a reason to treat the deploy and the first week of real usage as part of building the app, not an afterthought that happens after the “real work” is done.

A related failure mode worth knowing about separately: an app that doesn't crash outright but slows to a crawl or times out under real load. That's a different diagnosis with a different fix.

Keeping this from being a recurring event

A single production break is normal. The same break happening every few weeks means something structural is missing. A few habits fix that: set up basic error alerting so you find out about a crash before a user emails you about it, keep a record of every environment variable your app needs somewhere other than your memory, and treat each incident as a chance to add one guardrail, a null check, a fallback value, a health check endpoint, instead of only patching the exact symptom you hit. Ongoing maintenance is a real, recurring part of running an app built with AI tools, not a one-time setup cost, and it's worth planning for the same way you planned the build and the deploy itself.

FAQ

What's the very first thing to check when a production app goes down?

The deploy status, before the code. Confirm the most recent deployment actually finished successfully and matches the commit you think is live. A failed or partial deploy looks identical to a code bug from the outside, but no code fix will resolve it.

How do I find the real error if the platform doesn't show one clearly?

Check your hosting platform's runtime or function logs first, not just the browser console, since a server-side error often never reaches the browser. If nothing useful is there, add a temporary log statement right before the failing operation, redeploy once, and trigger your reproduction case again.

Should I roll back or fix forward?

If you have a known-good previous deploy and the break is affecting real users right now, roll back first to stop the bleeding, then debug calmly against a non-production environment. Fixing forward under live pressure is how second bugs get introduced on top of the first one.

How much code should I paste into the AI agent when reporting an error?

Enough for the agent to see the failing line in context: the function it's in, anything it calls directly, and anything that changed in the same deploy. Pasting an entire file when only ten lines matter buries the signal. Pasting one line with no surrounding context does the same thing in the other direction.

What if the app works for me but breaks for other users?

That's almost always either an environment variable set correctly for you but not for them, a permissions or auth difference, or a code path your own testing never exercises, like an empty account, a different browser, or a slower network. Reproduce with a fresh, logged-out session before assuming the fix worked.