Replit 502 Bad Gateway or 500 error after publishing: how to fix it

Publishing succeeded, and now the live app answers 502 Bad Gateway, Internal Server Error or Application failed to respond. Replit's help center is clear that when publishing succeeds and the app returns errors, the cause is in the app code, not in Replit's infrastructure. Here is how to find it quickly, and how to get users back online while you fix it.

Symptoms

• Some or all pages return 502, 500 or Application failed to respond.
• The app works for a while, then fails until it restarts.
• Logs show Exit code 1, UnhandledPromiseRejection, JavaScript heap out of memory or a Python traceback.
• Only one feature fails (upload, export, AI call) with a 500.

Likely causes

1. An unhandled exception or promise rejection crashes the Node.js process.
2. A missing secret or database error at startup, so the server never listens.
3. Out of memory: large files loaded in memory, a leak, or a machine too small for the work.
4. A slow request (AI call, big export) that times out.
5. A bug that only shows with production data, such as a null field that never existed in dev.

Step-by-step fix

1. Get users back first

If the app is down for real users, open Publishing → History, find the last version that worked and redeploy it. Then debug without pressure.

2. Find the first error in the logs

Open the deployment logs and scroll to just before the first 502. SIGTERM on Autoscale is normal (Replit stops idle instances). Exit code 1 means a crash, and the lines right above it say why.

3. Make crashes visible

process.on("unhandledRejection", (err) => console.error("Unhandled rejection:", err));
process.on("uncaughtException", (err) => { console.error("Uncaught exception:", err); process.exit(1); });

// Express: one error handler, registered last
app.use((err, req, res, next) => {
  console.error(req.method, req.path, err);
  res.status(500).json({ error: "Something went wrong" });
});

Wrap async route handlers so errors reach this handler instead of crashing the process.

4. Fix the root cause

For startup errors, check secrets and the database (see secrets in deployment). For memory errors, stream files instead of loading them whole, and check the machine size in the publishing settings. For timeouts, move long work to a background job and return early.

5. Republish and watch the logs

Publish the fix and keep the logs open while you repeat the action that failed.

Copy-paste prompt for Replit Agent

Open a new Agent chat (a fresh chat keeps old attempts out of its context) and paste this:

My published Replit app returns 502 / 500 / "Application failed to respond". Here are the deployment log lines just before the errors start:
[paste ~20 lines]
Please:
1. Explain the root cause in one sentence.
2. Add process-level handlers that log unhandledRejection and uncaughtException.
3. Add a final Express error handler that logs the error with method and path and returns a JSON 500, and make sure async route errors reach it.
4. Fix the root cause without removing the feature.
5. If memory is the problem, stream large files instead of reading them fully into memory.

How to verify the fix

• Repeat the failing action on the live URL: it succeeds, or shows a clean error message without a crash.
• Logs show no Exit code 1 over the next day of normal use.
• Monitoring in the Publishing pane shows the app healthy.

If Agent keeps fixing one crash and creating another, read how to stop the Replit Agent fix loop.

FAQ

What does 502 Bad Gateway mean on Replit?

Replit's proxy could not get a valid response from your app, usually because the process crashed or is not listening on the expected port. The deployment logs show the crash just before the 502s.

Is SIGTERM in my Replit logs an error?

No. Replit's help center explains that Autoscale deployments restart regularly by design and SIGTERM means a graceful stop. Exit code 1 is the one that signals a crash.

How do I roll back a broken Replit deployment?

Open Publishing → History, choose the last working version and redeploy it. Then fix the bug and publish again.