Replit app keeps going to sleep on its custom domain
Your Replit-hosted app is unreachable or painfully slow on the first visit after a quiet period — then fine. Webhooks time out, background tasks miss their windows, and it always works once you go look.
- Replit
- DNS & SSL
- Scheduled jobs
Root cause, in plain English
Only Replit Deployments are meant to stay reliably reachable — the workspace's dev URL stops serving when your session ends, and Autoscale deployments intentionally scale to zero when idle, so the first request after a lull pays a cold start that can feel like downtime and exceed webhook timeouts. A custom domain doesn't change any of this; it inherits the behavior of whatever it points at. Always-on needs a Reserved VM deployment.
How to fix it
Check what your custom domain actually points at: the workspace's dev URL means you're serving from the editor session — create a real Deployment and attach the domain to that instead.
Pick the deployment type by workload: Autoscale for request/response web apps that tolerate occasional cold starts, Reserved VM for anything that must be always-on — webhook receivers, schedulers, bots, websockets.
If you keep Autoscale, make startup fast (lazy-load heavy imports, avoid long init work) so cold starts shrink from "looks down" to "slightly slow".
Move scheduled work to a mechanism that doesn't depend on your app being awake: Replit's Scheduled Deployments or an external cron hitting an endpoint on a deployed (not workspace) URL.
Verify recovery behavior from outside: hit the domain after 30+ idle minutes and time the first response — that number is what your users and webhook senders experience.
How Nightlamp detects this automatically
- HTTP status
- Heartbeat
- Browser journey
An http_status check probes your custom domain at a steady interval and records response time, so scale-to-zero shows up as a recurring pattern of slow-or-failed first hits you can see and size. A heartbeat monitor catches background jobs missing their windows because the host was asleep, and a browser_journey confirms the app actually serves users — not just answers pings.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Does monitoring keep an Autoscale deployment awake?
- Frequent probes reduce how often you pay a cold start, but that's a side effect, not a guarantee — instances can still recycle between requests. If the business requirement is "always on", Reserved VM is the honest answer; monitoring's job is to tell you the truth about what users experience.
- Why do webhooks specifically break on a sleeping app?
- Webhook senders typically time out within seconds and may mark your endpoint as failing after repeated timeouts. A cold start that a patient human survives is fatal for a webhook delivery. Receive webhooks on always-on infrastructure.
- My app sleeps even though I deployed it. Why?
- Check which URL is in use — it's common for a custom domain (or an old link in a webhook config) to still reference the workspace dev URL instead of the deployment URL. The workspace serving while you develop makes this easy to miss.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.