My Replit app is down. What do I do?
When your Replit app is down, first check status.replit.com: if Replit lists an incident about publishing or published apps, the fix is on their side and you wait. If nothing is listed, the problem is in your deployment, and the Publishing pane's logs and history will usually show which part: the app crashed, it is not listening where Replit expects, a secret or the database address is missing in production, or the custom domain lost its verification.
Most of these can be fixed in an hour without touching much code: find the first error in the logs, put back the missing secret, restart or republish, or redeploy the last version that worked. The ones that take longer are database problems and a domain that has to verify again, which can take up to 48 hours.
If the app is down more than once, the fix is not another republish. It is an alert that tells you before customers do, a written way back to the last good version, and, for an app people pay for, hosting you control. That part is at the end.
In founders’ words
“We have been in regular contact with support, provided all requested information and followed every instruction given. However, we still do not have a working production system, no clear root cause explanation and no reliable recovery timeline.”
“There are no build errors, no runtime errors, and the deployment status shows healthy.”
“I've contacted support and been told someone will contact me but still haven't been contacted and its becoming urgent.”
Is Replit down, or is it my app?
Open status.replit.com (or its feed at status.replit.com/history.rss). Replit's own help pages say that if the outage is already listed there, "the team is working on it and a ticket won't speed up the fix". Subscribe to the incident and tell your customers you are waiting on your host.
Replit outages that hit published apps are not rare. Its incident history lists 52 incidents between May 11 and October 1, 2026, including "Publishing is down" on August 4, "Some Autoscale publishes are failing" on August 20 and "Publishing is broken due to db migration issue" on August 26. Some incidents stop new publishes and leave running apps alone; others degrade published apps while the editor works. So a failed publish during an incident does not mean your live app is down, and your live app being down does not always mean there is an incident.
If the status page is clear, look at your own app. Does it work in the Preview inside Replit? Replit's docs are blunt: "If Preview is broken, publishing will not fix it." If Preview works and the published app does not, the difference is almost always in production settings, covered below.
What the Replit error messages mean
- "Application failed to respond". Replit says your app is not listening on the port it expects. The app should read the PORT setting Replit gives it rather than a fixed number, and listen on 0.0.0.0, not localhost.
- A 502 error. Replit's docs say this "usually means your app process crashed or returned output the server couldn't use". The logs show the crash.
- Internal Server Error after a publish that succeeded. Replit says the issue is "in your app code rather than Replit's infrastructure". Something in production differs from Preview: a secret, the database, or a file the app expects.
- "The deployment could not be reached" or "Your app is not running". Replit's docs do not explain either message. In Replit's community forum, founders report them with a custom domain that lost its verification, an app that crashed on start, and during Replit-side incidents. Check those three in that order.
- "The endpoint has been disabled". Replit says this means the database compute was paused, often because of an unpaid invoice or a brief pause during publishing. Check billing first.
- Publishing fails at the last step (Promote). Publishing runs in five stages: Provision, Security checks, Build, Bundle and Promote. Failing at Promote usually means the app built but did not start in time: it did not open its port, it took more than five seconds to answer on the home page, or the ports in the .replit file do not include one mapped to external port 80.
How to get the app serving again
In this order. Most outages end at step two or three.
- Read the logs. Open the Publishing pane, then Logs for a running app, or History and the failed deployment for a build that failed. Find the first line marked ERROR or FAILED; the lines after it are usually consequences. In the logs, a SIGTERM on an Autoscale app is normal; "Exit code 1" means the app crashed by itself.
- Check production secrets. Secrets you set while building do not carry over to the published app. Replit keeps development and production secrets in separate places, under Publishing, Adjust settings, Production app secrets. A missing API key or database address is the most common cause of "works in Preview, broken live".
- Check the database address. The published app uses its own production database, not the one you built against. If data looks missing, it may be in the development database, and the shut-down of Replit's old shared databases in June 2026 left some apps pointing at nothing.
- Restart or republish. Search for Restart compute (Cmd+K or Ctrl+K) when a deployment hangs. Publish again rebuilds from your current code even if nothing changed.
- Go back to the last version that worked. Replit's help pages disagree on how: one says to redeploy the last working version from Publishing, History; another says rolling a published app back is no longer supported and you should restore a checkpoint and publish again. Try History first. Either way, a checkpoint rollback does not restore the production database.
- Check the custom domain. The replit-verify TXT record has to stay in your DNS for as long as the domain is in use; if it is removed, the domain will eventually serve an expired certificate and the app looks down. Unpublishing also removes custom domain connections, so re-add them after a republish. DNS changes can take up to 48 hours.
Replit shut down the old shared database. My app is down or missing data. What now?
When the Replit app is slow, not down
Autoscale, the default way Replit publishes an app, goes idle after 15 minutes with no traffic and can scale down to nothing. The first visitor after that waits a few seconds while it starts again. Replit calls that a normal cold start. If the first load of the morning is slow and the rest are fine, that is what you are seeing, and a Reserved VM, which never sleeps, is the setting that changes it.
If every page is slow, the usual causes Replit lists are database queries with no index, code that blocks while it waits, and memory that grows until the app restarts. Those are code fixes, and they get worse with every new customer.
What to do when Replit support does not answer
Know what your plan includes before you need it. Replit's support policy says Core plans get AI-powered support, and only billing questions can be escalated to a person. Pro and Enterprise get support engineers, staffed Monday to Friday, 6 am to 6 pm Pacific. On every plan, Replit says support is "unable to provide hands-on debugging or fixes for individual application-level code". If the problem is in your app, support will not fix it.
Open a ticket through Get Help inside Replit with the deployment's name, the time it went down, the first error line, and what you already tried. If the logs point at Replit's side (a deployment that builds and then fails with no error, or a setting that changes by itself), say so in the first line. Meanwhile, tell your customers what is happening and when you will update them, even if you do not know the cause yet.
How to stop it happening again
- Turn on Enable app monitoring in the publishing settings (Core, Pro and Enterprise). Replit checks the app on a schedule and emails you if it goes down. Replit keeps deployment logs for 30 days.
- Keep the code in GitHub from Replit's Git pane, so a working version exists outside Replit and you can see exactly what changed before a break.
- Write down the production settings: every secret name, the database, the domain records. A one-page list turns a missing-secret outage into a five-minute fix.
- Test before publishing. The Preview has to work, and the paths that make money (sign-up, log in, pay) should be checked after every publish.
- Decide where the app should live. For a tool you use alone, Replit is fine. For an app customers depend on, hosting and a database in your own account mean an outage is yours to fix rather than yours to wait on.
When you may not need help, and when you do
If the app came back after a secret fix or a republish, nobody pays for it yet, and it has gone down once, you probably do not need anyone. Turn on monitoring, keep the code in GitHub, and keep the list of production settings.
Bring someone in when the app has been down more than a day, when it keeps going down for reasons nobody can name, when customers or staff rely on it for daily work, or when Replit support says the problem is in your code and you cannot read it. At that point the questions are where the app should run and what is fragile in it, which is what our free call is for.
| What you see | Usual cause | First check |
|---|---|---|
| Everything down, including the editor | A Replit incident | status.replit.com |
| Application failed to respond | The app is not listening on Replit's PORT, or on 0.0.0.0 | The start command and the first lines of the logs |
| 502 error | The app crashed | Logs: the first ERROR line and any "Exit code 1" |
| Works in Preview, errors when published | A secret or the database address is missing in production | Publishing, Adjust settings, Production app secrets |
| Publishing fails at Promote | The app did not start in time, or no port maps to 80 | Build logs in Publishing, History; the .replit ports |
| Custom domain down, replit.app address works | Lost domain verification or a removed TXT record | Your DNS records against Replit's domain settings |
| First load slow, the rest fine | Autoscale cold start after 15 idle minutes | Nothing to fix; Reserved VM if it matters |
| "The endpoint has been disabled" | Database compute paused, often billing | Billing, then the Database panel |
Questions
Is Replit currently down?
Check status.replit.com, Replit's own status page, or its incident feed at status.replit.com/history.rss. If an incident about publishing or published apps is open, wait for it and subscribe to updates. If nothing is listed and your app is down, the cause is most likely in your deployment.
Why does my Replit app work in Preview but not when published?
The published app has its own secrets and its own production database. Secrets set while building do not carry over, and the database address points at production, not the development database you tested with. Compare the two and add whatever is missing under Production app secrets.
How do I roll back a Replit deployment?
Try Publishing, History and redeploy the last version that worked. Replit's help pages disagree on whether that is still supported; the other route is to restore a checkpoint and publish again. Neither restores the production database, which has its own point-in-time restore (7 days on Core, 28 on Pro).
Can I get notified when my Replit app goes down?
Yes, on Core, Pro and Enterprise. Turn on Enable app monitoring in the publishing settings and publish; Replit checks the app on a schedule and emails you if it goes down. An outside uptime checker on your main page is a good second alarm.
Will Replit support fix my app?
Not if the problem is in your app's code. Replit's support policy says it cannot do hands-on debugging of application code. Support helps with platform problems; on Core it starts with AI support, and only Pro and Enterprise get support engineers.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.