Why does my Replit app go to sleep? Deployment types explained

A Replit app "goes to sleep" for one of two reasons. Either people are using the development URL (replit.dev), which only works while you're actively working in the project, or the app is published as an Autoscale deployment, which scales down to zero servers when nobody is using it and has to start up again on the next visit. The fix is to share the published URL and to choose the deployment type that matches how your app behaves.

This guide explains the four deployment types in plain terms, which symptoms each one causes, and what to change so the app responds when your users need it.

Why does my app stop working when I close Replit?

If you sent people a link that looks like something.replit.dev, that is a development URL. Replit's docs describe these as temporary preview links for testing: they're only live while you're working on the app, and the address can change when you reopen the project.

So the app didn't crash. It was never deployed. Publish it from the Publishing pane and share the published address (or your custom domain) instead. Our guide on Replit deployment failures helps if publishing itself doesn't go through.

What are Replit's deployment types?

Replit offers four ways to run a published app. They differ in whether a server is always running and how you pay.

Autoscale is Replit's default and the right choice for most apps. The sleeping behaviour comes with it.

Why is the first visit so slow?

With Autoscale, when no requests arrive for a while, the number of servers can drop to zero, so you're not paying for quiet time. The next visitor triggers a fresh start: the platform boots your app, runs its startup code and only then answers. That first response is noticeably slower than the ones after it. Replit doesn't publish a fixed number for this delay, and it depends heavily on your own app.

What your app does at startup matters more than anything you can configure. Apps generated by an AI agent often:

• Run database migrations or seed scripts every time the server starts.
• Load large files or datasets into memory before listening.
• Import heavy libraries that the first page doesn't need.
• Call an external API (an AI model, a CRM) during boot.

How do I make the wake-up faster?

1. Start listening first, then do optional work. A server that answers in a fraction of a second and loads extras afterwards feels far faster.
2. Move migrations out of the start command. Run them as a deliberate step when you publish, not on every boot.
3. Load data on demand and cache it, instead of reading everything at startup.
4. Check the publishing logs for the time between "starting" and the first request being served. Measure before and after each change.

Fast startup also keeps you clear of Replit's health check, which can fail a publish if the homepage takes more than five seconds to respond.

Why do my scheduled tasks and timers stop running?

An app that scales to zero has no server running between visits. Anything that depends on the process staying alive stops too:

• setInterval or cron-style timers inside the web server.
• Queues processed in memory.
• WebSocket connections and chat bots that must stay connected.
• Data kept in a variable instead of a database (it's gone on restart).

If your app does work on a timer, either move that work into a Scheduled deployment that runs at set times, or run the whole app on a Reserved VM, which Replit describes as a dedicated machine that never sleeps and is meant for things like chat bots and always-on API servers.

Should I ping my app to keep it awake?

You'll find advice to hit your Autoscale app every few minutes from an outside monitor so it never scales down. It can work, but think about what it means: with Autoscale you pay while requests are being served, so you're paying to keep it busy, and you're turning a pay-per-use deployment into a worse version of an always-on one.

A better rule: if your users can't tolerate a slow first request, or the app needs to run work in the background, choose Reserved VM and pay a known monthly amount. If a short delay on the first visit of the morning is fine, stay on Autoscale and make startup fast.

An uptime monitor is still worth having for a different reason: it tells you when the app is actually down. Our guide to monitoring and error tracking covers that.

How do I choose the right deployment type?

Ask three questions:

1. Does the app have any server code? If not (just HTML, CSS and JavaScript calling outside services), Static is cheapest and doesn't have a server to wake up.
2. Does anything need to run when no one is visiting? Timers, bots, open connections or queue workers point to Reserved VM, or to a separate Scheduled deployment for timed jobs.
3. How much does a slow first request cost you? A booking page that loses customers if it hesitates is a different case from an internal tool used by three people.

You can change the deployment type later in the Publishing pane. Costs differ between types, so check Replit's current pricing for your plan, and see our overview of what hosting really costs.

Quick answers

Why does my Replit app stop when I close the browser? You're probably sharing the replit.dev development URL, which only works while you're in the project. Publish the app and share the published URL.

Does Replit Autoscale sleep? It scales down to zero servers when idle, so the first request after a quiet period has to start the app again.

How do I keep a Replit app always on? Use a Reserved VM deployment, which runs on a dedicated machine that never sleeps.

Why did my Discord bot or background job stop? On Autoscale nothing runs between requests. Move the bot to Reserved VM and timed jobs to a Scheduled deployment.

Need help choosing or fixing the setup?

If your app is slow to wake because of what it does at startup, that's a code fix, not a hosting plan. Our Replit app rescue looks at both, and ongoing help is available through software maintenance and support. You can run the free health check first, or tell us what's happening.