Your Replit app stopped working — or was it never really deployed?
If your Replit app vanishes when you close the tab, you shared the development URL — those only stay live while you're working in the editor; publishing gives you a permanent .replit.app address. Already published? Then check deployment secrets (workspace secrets don't carry over), 0.0.0.0 port binding, autoscale cold starts, and the separate production database. Each check below maps a symptom to the documented fix.
The editor is a workshop. The deployment is the shop floor.
Replit draws a hard line between the workspace (your editor, dev URL, dev database, workspace secrets) and the published deployment (its own URL, its own secrets, a production database on Neon, real health checks). Apps built quickly — especially with Replit Agent — tend to get shared straight from the workshop side of that line. Everything on this page is some version of the same mistake: expecting the workshop's conditions to hold on the shop floor.
Seven ways a Replit app breaks — symptom, then fix
The app dies when you close the tab
Symptom: Your shared link works while you're editing, then goes dark minutes later.
Fix: That's a development URL (UUID.servername.replit.dev) — documented as live only while you actively work on the app, and intended for testing. Publish the app: deployments get a permanent .replit.app URL that doesn't care whether your editor is open. (Always On and repl.co hosting were retired at the start of 2024 — deployments are the path.)
First request hangs after a quiet period
Symptom: The app responds, but the first visitor each morning waits several seconds.
Fix: Autoscale scales to zero when idle; Replit documents the first request after a quiet period taking a few seconds as a normal cold start. If that's unacceptable — or you run background tasks, bots that must stay connected, or an always-on API — Replit's own positioning says use a Reserved VM. Periodic jobs belong on Scheduled deployments, not a sleeping web server.
Works in the editor, fails deployed: missing secrets
Symptom: Undefined values, failed API calls, DB connection failures, login or payment errors — deployment only.
Fix: Documented behavior: secrets set in the editor do not automatically carry over to your published app. Add every secret to the deployment configuration and republish. Account-level secrets must be linked to the app before they apply. Note secrets aren't available on Static deployments at all.
"Application failed to respond" or publish fails at the last step
Symptom: The deployment builds, then never answers — or the final health check fails.
Fix: Bind to 0.0.0.0, not localhost/127.0.0.1 — Replit requires it for deployments. Check .replit's [[ports]] mapping: the localPort must match what your program actually listens on (external port 80 is the default; Autoscale and Reserved VM expose a single external port). And if your homepage takes more than five seconds to respond, the publish health check can time out — make the root route fast.
Production database is empty — or drops connections
Symptom: Data you created while building is missing in production; idle apps see dropped sessions.
Fix: Dev and production databases are separate by design; publishing applies schema changes but not data. Production runs on Neon and idles after about five minutes without queries — reactivation is fast, but session state (temp tables, prepared statements, advisory locks, LISTEN/NOTIFY) doesn't survive. Reconnect-on-failure logic and re-seeding production data are the fixes.
Custom domain broken — sometimes weeks later
Symptom: The domain verified fine, then the certificate failed to renew or the domain went dark.
Fix: Replit requires an A record plus a replit-verify TXT record — and the TXT record must stay in your DNS for the domain's entire lifetime; deleting it after verification breaks certificate renewal. Also documented: no AAAA records alongside the A record, no duplicate A records to different servers, and no Cloudflare proxying (it blocks automatic cert renewal). Propagation can take up to 48 hours.
Your app URL changed after unpublish/republish
Symptom: Old links and webhook endpoints 404 after you republished.
Fix: Documented: the .replit.app subdomain is not guaranteed to persist across unpublish/republish. Re-check every place the old URL lives — webhook endpoints, OAuth redirect URIs, links in emails — or put a custom domain in front so the platform URL can change without breaking anything.
Paste this into your incident notes
Replit app triage
[ ] Which URL is broken: *.replit.dev (dev — sleeps by design) or *.replit.app (deployed)?
[ ] Not deployed yet? Publish. Dev URLs are not hosting.
[ ] Deployment secrets: every key from the workspace re-added to the deployment? Account
secrets linked to this app?
[ ] Server binds 0.0.0.0 (not localhost). .replit [[ports]] localPort matches the real port.
[ ] Root route answers fast — slow homepages can fail the publish health check.
[ ] Autoscale + background jobs/bots? Move them to Reserved VM / Scheduled deployments.
[ ] Production DB: schema current? Data seeded? Reconnect logic for Neon idle resume?
[ ] Custom domain: A + replit-verify TXT both still present (TXT must NEVER be deleted);
no AAAA, no Cloudflare proxy.
[ ] Republished recently? The .replit.app URL may have changed — update webhooks/redirects.How Nightlamp catches this before your users do
The failure modes above are exactly the ones an external monitor sees first: an http_status check on the .replit.app URL (and your custom domain) catches "Application failed to respond", URL changes after a republish, and DNS breakage; its response-time trend makes cold starts visible instead of anecdotal. An api_canary that queries a database-backed endpoint proves the production DB connection survives Neon's idle pauses. A heartbeat check wraps your Scheduled deployment — if the job doesn't ping, you find out from us, not from the missing report. And an ssl check warns you while a deleted TXT record is still a renewal problem, not an outage.
Replit troubleshooting FAQ
Why does my Replit app stop when I close the tab?
You're on the development URL — live only while you're working in the editor, by design. Publish the app for a permanent .replit.app URL.
Why is the first request slow?
Autoscale scales to zero; the documented cold start takes a few seconds after a quiet period. Always-on workloads belong on a Reserved VM; periodic jobs on Scheduled deployments.
Why are my API keys missing in the deployment?
Editor secrets don't carry over to published apps — documented behavior. Add them to the deployment configuration (and link account-level secrets to the app), then republish.
Why is production data missing?
Production gets its own isolated database when you publish; schema syncs, data doesn't. Production runs on Neon and pauses when idle — sessions don't survive the pause.
Why did my custom domain break weeks after setup?
Usually the replit-verify TXT record was deleted after verification — it must stay for certificate renewal — or the domain is proxied through Cloudflare, which Replit documents as blocking automatic cert renewal.
Want to know the moment the deployment goes dark?
Point Nightlamp at your .replit.app URL, your custom domain, and the scheduled jobs that keep the business running. When something breaks, you get the documented cause — bind address, missing deployment secret, dead TXT record — not just "down".
Start 14-day trial · no cardNewsletter
One real no-code incident + the fix, monthly
A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.
Double opt-in. One-click unsubscribe. No spam, ever.