Replit Not Working? 10 Common Errors and How to Fix Them

Jump to your symptom: Replit itself won't load · Preview blank or app not running · publishing fails · works in Preview, breaks live · live database is empty · changes don't show on the live site · uploaded files disappear · slow first load · custom domain or SSL · Agent broke something that worked

Before You Touch the Code: 4 Quick Checks

1. Check whether Replit itself is having problems. Open Replit's status page. If there's an active incident, wait for it to clear before changing anything.
2. Find out where it breaks. Click Run at the top of the Project Editor and open Preview. If Preview is broken too, start with Error 2. If Preview works and only the published app is broken, the cause is almost always in the publishing setup (Errors 3 to 7), not your code.
3. Suspect the last change first. If the app worked before the Agent's last edit, roll back to a checkpoint before asking for more changes (Error 10).
4. Read the exact error. The Logs tab of the Publishing pane, the Preview's Devtools, or the Agent's message tells you which section below applies. Copy the text word for word.

Error 1 - Replit Not Loading or Not Opening

What you see: the Replit workspace spins forever, opens blank, or stops responding, even for projects that haven't changed.

Why it happens

When nothing in your project changed, the cause is outside it: a Replit incident, or something in your browser getting in the way.

How to fix it

1. Check status.replit.com for an ongoing incident.
2. Hard-refresh the page: Cmd+Shift+R (Mac) or Ctrl+Shift+R (Windows/Linux).
3. Open Replit in a private window, or in another browser, with extensions turned off. If it loads there, one of your extensions or cached files is the problem.

What you should see: the Project Editor opens and the Run button responds. If the status page shows an incident, the only fix is to wait.

Error 2 - Replit Preview Not Working or "App Not Running"

What you see: you click Run and Preview stays blank, shows an error page, or never shows your app at its replit.dev address.

Why it happens

Preview runs your app the same way a browser would. If it doesn't show the app, the app is failing to start or crashing, usually because of the last change. Replit's documentation is explicit: if Preview is broken, publishing won't fix it.

How to fix it

1. Click Run at the top of the Project Editor and open the Preview tab.
2. Click Devtools (the wrench icon) at the top of the Preview tab and look for red error lines in the console. Copy the exact text.
3. Ask the Agent to diagnose Preview, and paste the exact error. Be specific: "Preview is blank after the login page change, and the console shows this error" gets better results than "nothing works, fix it."
4. If the problem started with the Agent's last change, roll back instead (Error 10).

What you should see: your app loads in Preview at a replit.dev URL with no red errors in Devtools. Only then move on to publishing.

Error 3 - Replit App Not Publishing (Works in Preview, Publishing Fails)

What you see: the app runs fine in Preview, but publishing stops with an error, or it seems to finish and the public URL doesn't respond or shows a 404 "not found" page.

Why it happens

Published apps have rules that Preview doesn't enforce. The three most common, from Replit's troubleshooting guide:

• The server listens on the wrong address. It must listen on 0.0.0.0. Listening only on localhost or 127.0.0.1 doesn't work for published apps.
• The port setup doesn't match. If your .replit file lists ports, Replit stops detecting them automatically. One port needs externalPort set to 80, and its localPort must be the port your server actually listens on.
• The home page is too slow. If your homepage takes more than five seconds to respond, the health check can time out and publishing can fail.

How to fix it

1. Open the Publishing pane and read the Logs tab. The last lines before the failure usually name the problem.
2. Check how your server starts. In a Node.js app, for example, it should look like app.listen(port, "0.0.0.0"), not app.listen(port, "localhost").
3. Open .replit and check the ports section: one entry with externalPort = 80, and a localPort that matches your server's port.
4. If the home page does heavy work before answering (loading large data, calling slow APIs), make it respond right away and do that work afterwards.
5. Publish again.

What you should see: publishing completes and the public URL loads the same page you see in Preview. For more failure messages and their causes, see Replit deployment failed.

Error 4 - Works in Preview, Breaks When Published (Missing Secrets)

What you see: the published app loads, but logins fail, payments fail, API calls return errors, the database won't connect, or the logs mention an undefined value. In Preview, all of it works.

Why it happens

Secrets are the private values your app needs, such as API keys and database passwords. Secrets you set in the Project Editor do not automatically carry over to your published app. Replit keeps the two separate, so a key that exists in Preview can be missing live.

How to fix it

1. In the Project Editor, list the names of every Secret your app uses. You need the names, not the values, to compare.
2. Open the Publishing pane, where the published app's own Secrets are set.
3. Add every production Secret and environment variable there, with the value meant for the live app. For services with test and live keys, like Stripe, use the live key here.
4. Publish again so the published app picks up the new values.

What you should see: the failing feature works on the published URL, and the "undefined" errors disappear from the Logs tab.

Never paste a secret key into the Agent chat, a public file or front-end code to "make it work." Keep it in Secrets, where only the server can read it.

Error 5 - Data Shows in Preview but the Live App Is Empty

What you see: the records you created while building are there in Preview, but the published app shows empty lists, or data your users enter live doesn't appear in Preview.

Why it happens

This is how Replit is designed. Your published app gets its own production database, separate from the development database you use while building. After publishing, the live app uses production and the Project Editor keeps using development, so changes you make while building don't touch live data. When you publish, changes to the database's structure (new tables or columns made with the Agent) are applied to production. Your development records are only copied if you turn on Set up your production database with your current development data when setting up the production database.

How to fix it

1. Confirm which database you're looking at: Preview shows development data, the published URL shows production data.
2. If production is empty after your first publish and you didn't turn on the copy option, that's expected. Create real accounts and records through the live app.
3. To look at or correct live data by hand, open the Database tool, select the production database, open My Data and toggle Edit. Change one record at a time, and only when you're sure: these are your users' real records.
4. If a new column or table is missing live, publish again so the structure change is applied to production.
5. If the live app can't connect to the database at all, check the logs and see Replit database connection errors.

What you should see: the live app shows the data your users created there, and new tables or columns appear after publishing.

Only copy development data into production if it's safe to show in your live app. Test accounts, fake orders and sample data would all become visible to real users.

Older apps that suddenly stopped working: if your app was remixed from another app that had a database before January 9, 2026, it may have been sharing that app's database. Replit shut those shared legacy databases down on June 8, 2026. Replit has a guide to fix a published app using a shared database.

Note that the Agent can't edit your production database. That's deliberate, to keep live data safe, so asking it to "fix the live data" won't work.

Error 6 - Changes Don't Show Up on the Live Site

What you see: you or the Agent changed something, Preview shows the new version, and the published URL still shows the old one.

Why it happens

Publishing takes a snapshot of your files and dependencies at that moment. The published app keeps running that snapshot until you publish again.

How to fix it

1. Check the change works in Preview first.
2. Open the Publishing pane and publish again to create a fresh snapshot.
3. Once it finishes, hard-refresh the published URL (Cmd+Shift+R or Ctrl+Shift+R) so your browser doesn't show a cached copy.

What you should see: the published URL matches Preview.

Error 7 - Uploaded Files or Saved Data Disappear After Publishing

What you see: images users uploaded, generated files, or data saved to a local file vanish after you publish again.

Why it happens

A published app's file system is not persistent: it resets every time you publish. Anything your app writes to its own folders is lost with the next snapshot.

How to fix it

1. Find where the app saves files or data. Ask the Agent: "Where does the app write uploaded files or data to disk?"
2. Move that storage to Replit's Storage or Database options instead of the app's own folders.
3. Publish again and test with a new upload.

What you should see: uploaded files and saved data survive the next publish. Files lost in earlier resets can't be recovered from the published app.

Error 8 - App Is Slow to Load After Being Idle

What you see: the first visit after a quiet period takes several seconds, and later visits are fast.

Why it happens

Autoscale deployments scale to zero when there's no traffic, which keeps costs down. The next visitor has to wait while the app starts again. Replit's old paid option for keeping a repl awake around the clock no longer exists: it was retired on January 1, 2024, when Deployments replaced it. Advice to switch that option on, or to ping your app every few minutes to keep it awake, is out of date.

How to fix it

1. Open the Publishing pane and check which deployment type the app uses.
2. If occasional slow first loads are acceptable, keep Autoscale and make startup lighter (see step 4 of Error 3).
3. If the app has to answer instantly at any time, switch to a Reserved VM deployment, which runs continuously. Pricing differs by type, so check Replit's pricing page before switching.
4. If the site is only pages that don't change per user, a Static deployment has no server to start.

What you should see: with a Reserved VM, the first visit loads as fast as the rest.

Error 9 - Replit Custom Domain Not Working

What you see: the replit.app address works, but your own domain doesn't load, shows a security warning, or never reaches Verified.

Why it happens

Your domain needs two DNS records at your registrar: an A record pointing to Replit and a TXT record starting with replit-verify=. Replit issues the SSL certificate itself. Most failures come from an extra or missing record.

How to fix it

1. Make sure the app is published. The Domains tab only appears in the Publishing pane after a successful publish.
2. In Domains, choose Connect your own domain. Either let the guided setup configure DNS for you, or copy the A and TXT values into your registrar's DNS settings.
3. Remove any other A records for the same name that point elsewhere, and any AAAA (IPv6) record. Having A and AAAA records at the same time blocks the SSL certificate.
4. If you use Cloudflare, set the record to DNS only (gray cloud), not proxied.
5. Add www separately. It's a subdomain and needs its own A and TXT records.
6. Leave the replit-verify= TXT record in place permanently. Replit uses it to renew the certificate.
7. Wait. Verification usually takes minutes but can take up to 48 hours.

What you should see: the domain shows Verified in the Domains tab and loads over https with no warning. If your app has sign-in with Google or another provider, add the new domain to that provider's allowed redirect URLs too.

Error 10 - Replit Agent Broke Something That Worked

What you see: after the Agent's last change, a feature that used to work is broken, and each new request to fix it breaks something else.

Why it happens

Each Agent change can touch many files at once. Asking for fix after fix on top of a broken state usually piles up more changes instead of undoing the one that caused the problem.

How to fix it

1. Stop asking for new fixes.
2. Open the Agent tab in the Project Editor and find the last checkpoint from before the problem. The Agent creates checkpoints automatically when it finishes a feature, at milestones, and before it tries to fix critical errors.
3. Click Rollback to here, read the warning, and confirm. This restores the project files, dependencies, settings and the Agent conversation to that point.
4. The database is only restored if you select Database in the additional rollback options. Leave it unticked unless the Agent also damaged your data, because restoring it replaces what was added since.
5. Ask for the change again in smaller steps, and check Preview after each one.

What you should see: the app works in Preview as it did at that checkpoint. The live app only changes when you publish again (Error 6). If the Agent is stuck in a loop rather than breaking things, see Replit Agent not working.

What Replit Actually Does (Common Misunderstandings)

• The old keep-awake option is gone. It was retired on January 1, 2024. Today you choose a deployment type: Autoscale scales to zero when idle, Reserved VM runs continuously, Static serves pages without a server, and Scheduled runs at times you set.
• Preview and the published app don't share Secrets. Production Secrets go in the Publishing pane.
• Preview and the published app don't share data. Development and production databases are separate by design.
• The published app's disk isn't storage. It resets on every publish. Use a database or Replit's Storage.
• Publishing is a snapshot. Nothing reaches the live app until you publish again.

When It Isn't a Bug

• A slow first load on Autoscale after a quiet period is the cost of scaling to zero, not a fault.
• An empty production database after the first publish is expected, unless you chose to copy your development data.
• The Agent refusing to change production data is a safety rule, not an error.
• Size limits are real: Autoscale and Reserved VM deployments can be up to 8 GB, Static deployments up to 1 GB.
• If you've decided to move the app off Replit, that's a migration project, not a fix. See moving a Replit app to Vercel.

What to Include When You Ask for Help

Whether you ask the Agent, Replit support or a developer, include:

• Where it breaks: the editor, Preview, publishing, or the live URL.
• The exact error text from the Logs tab or Preview Devtools, copied word for word.
• When it last worked, and what changed since (an Agent request, a new Secret, a domain change).
• The deployment type (Autoscale, Reserved VM, Static or Scheduled).
• The names of your Secrets, never their values.

Frequently Asked Questions

Still broken after this guide?

If your Replit app keeps failing in ways this guide doesn't cover, the AppStuck Master Prompt gets your AI builder to write up the problems in your app, so you can see what's wrong before you change anything else. It's free. Get the Master Prompt.

Sources

• Replit docs: Troubleshoot publishing (verified 23-sep-2026)
• Replit docs: Preview (verified 23-sep-2026)
• Replit docs: About deployments (verified 23-sep-2026)
• Replit docs: Development and production databases (verified 23-sep-2026)
• Replit docs: Custom domains (verified 23-sep-2026)
• Replit docs: Fix a published app using a shared database (verified 23-sep-2026)
• Replit docs: Checkpoints and rollbacks (verified 23-sep-2026)
• Replit blog: Hosting changes (verified 16-sep-2026)
• Replit blog: Autoscale deployments (verified 16-sep-2026)
• Replit status page