Free site slow to open the first time? Autosleep on BrewInTH explained
Why a Free site sometimes shows a “waking up” page, which sites never sleep, how to keep a site always on, and what mobile apps and webhooks should do.
You finish your site and send the link to a friend or a customer — and they land on a "waking up" page and wait several seconds before the site appears. The next visit is fast again. Many people assume the site is broken or the server is slow. In fact it is autosleep, working exactly as designed.
This article explains what autosleep is, why the Free package has it, which sites never sleep, where to see the state, and what your options are when a site has to be ready for real customers at all times.
In short
🌙 On the Free package, an app with no visitor for more than 3 days is put to sleep; the first visitor after that waits about 10–40 seconds, then the site works normally
🌙 Nothing is lost — the database does not sleep
🌙 Static sites (plain HTML, CSS, JS) and sites shown on the portal never sleep
🌙 Paid packages choose for themselves, and the default is never to sleep
🌙 Mobile apps and webhooks should retry a 503 after a few seconds
What is autosleep?
A site with server-side code (Node.js, PHP, Python and so on) needs a program running and waiting all the time, using the machine's CPU and memory even when nobody visits. Many test sites on the Free package are opened a few times and then forgotten. If every one of them stayed running, the machines would fill up and a free service could not last.
So autosleep stops an app's program for a while when nobody has visited for a long time, and starts it again on its own the moment someone arrives — nobody has to press anything.
When does it sleep?
On the Free package, an app sleeps once it has had no visitor for more than 3 days, counted from the last request. A site that gets visitors every day hardly ever sleeps.
How does it wake, and what do visitors see?
The first visitor after the app fell asleep sees a short waking-up page in Thai and English. It reloads itself every few seconds, and once the app is ready (about 10–40 seconds, depending on the app) the visitor sees the site as usual, without refreshing by hand. Everyone after them gets the normal speed.
What keeps running
- The database keeps running; no data is lost.
- Files in persistent storage (
/bw-data) stay as they are. - The address and HTTPS don't change.
Only the app's program sleeps.
Which sites never sleep?
- Static sites. A site made only of HTML, CSS, JavaScript and images is served straight from files, with no program to pause — so it is always fast, even on the Free package. Shop pages, portfolios, landing pages and most HTML5 games can be built this way.
- Sites shown on the portal (portal.brewinth.com), on any package including Free. While the site's listing is approved and the owner hasn't opted out, it does not sleep, so visitors coming from the portal never meet the waiting page. If it leaves the portal, the package's rule applies again.
- Sites on a paid package choose for themselves, and the default is Never (always on).
Where to see the state and change it
Open your project, go to the App settings tab and find the Autosleep panel (static sites don't have it, since they never sleep).
- The state shows Awake, Asleep (saving resources) or Waking up.
- Last request tells you when the site last had a visitor.
- While the app is asleep there is a Wake now button — handy before you send the link to a customer or start a demo, so nobody sees the waiting page.
- On the Free package the panel tells you the idle period and that it can be adjusted or disabled with a paid package.
- On a paid package, the Sleep field offers Never (always on) or sleeping after 15 or 30 idle minutes, 1, 3 or 12 idle hours, 1 idle day or 3 idle days; then press Save.
- For a site shown on the portal, the panel says it stays on because it is on the portal.
What mobile apps, APIs and webhooks should do
The waking-up page is for people in a browser. When the request comes from a program — a mobile app, another site calling your API, a webhook — the platform answers HTTP 503 with Retry-After: 5 and JSON containing "error": "runtime_waking" while the app starts.
What to do:
- Mobile apps and pages that call an API should retry automatically on a 503: wait as
Retry-Aftersays, try again 5–8 times, and show "loading" rather than an error. - Webhooks from other services (LINE, payment providers) may not resend after a 503, so the message can be lost. Important webhooks belong on a paid package set to never sleep.
- Don't redeploy to fix the waking page. It is not a sign of a broken site; a few seconds later it is awake.
A prompt to make your app cope
This site/API runs on BrewInTH's Free package, which may put the app to sleep
after a long time without visitors. While it wakes, the platform answers
HTTP 503 with Retry-After and {"error":"runtime_waking"}. Please update the client:
- Retry every API call automatically on a 503, waiting as Retry-After says
(5 seconds by default), at most 8 times, showing "Getting things ready…" meanwhile.
- Do not retry other 4xx errors.
- Make the app start fast: move heavy start-up work (migrations, loading big data)
out of the start step into the release command, or do it on first use.Three ways to keep a site always ready
- Make it static if you can. If the site only shows information, with no login or database, ask your AI to build it as plain HTML, CSS and JS. It will always be fast and never sleep, even on Free.
- Get it on the portal. For a site, game or tool you want people to discover, keep the project's portal switch on. Once staff approve the listing, the site does not sleep while it is shown.
- Use a paid package. From Starter at ฿99/month or Seed at ฿749/year, set to Never (always on) — already the default. Right for sites with real customers, back-office systems, bots and mobile-app APIs.
FAQ
Is data lost while the app sleeps?
No. The database doesn't sleep and files in persistent storage stay. Only what the app kept in memory is gone, such as sessions that weren't stored in the database or Redis.
Why was my site fast right after deploying but slow days later?
While you deploy and people visit, the app runs normally. If nobody visits for more than 3 days on the Free package, it is put to sleep, so the first person to return meets the waking page.
My static site is slow — is that autosleep?
No, static sites never sleep. Slowness there usually comes from large files such as images or videos that were never resized; ask your AI to compress the images and load them lazily.
Do scheduled jobs (cron) still run while the app sleeps?
Scheduled jobs run separately from the website. If your job needs to call your own site, use a paid package set to never sleep, so the app is always ready to answer.
Can I make a paid site sleep sooner? Why would I?
Yes, from 15 minutes up. It suits test or spare sites on a paid package that don't need to hold resources all the time.
Summary
The waking-up page is not a broken site: it is the Free package's autosleep after more than 3 days without a visitor. Your data stays intact and the site wakes on its own within a few dozen seconds. If a site must always be ready, make it static, put it on the portal, or use a paid package set to never sleep — and have mobile apps and API-calling pages retry on a 503.
See the packages and start for free →