Why Your Streamlit App Keeps Sleeping (2026): the 12-Hour Rule and What to Do

You built a Streamlit app. You deployed it to Community Cloud. You sent the link to your team. And the next morning someone messages you: "it says the app is sleeping?"

This is the single most complained-about issue on the Streamlit forum. The thread titled "Web apps keep on sleeping after 30 minutes or a day of inactivity" has 26 posts and keeps growing. Another thread, "How to prevent the app entering sleep mode?", is just as active. A broader "Hosting Streamlit: discussion on options" thread reads like a support group for people who've hit the wall.

If you're here because your app fell asleep at the worst possible time, you're not alone.

Here's why it happens, why the common workarounds are fragile, and what your actual options are in 2026.

The sleep is a feature, not a bug

Community Cloud is free hosting. Streamlit (now part of Snowflake) runs your app on shared infrastructure at no charge. The sleep mechanism is how they keep that economically viable.

Here's how it works: if nobody visits your app for a stretch of inactivity — currently 12 hours — the platform spins your app down. The inactivity window has shrunk over time: it started at 7 days, was later reduced to 72 hours on weekdays, and now sits at 12 hours. Each reduction caught app owners off guard, because there's no migration notice — the window just gets shorter and apps that were fine start sleeping.

When someone visits a sleeping app, they see a "This app is sleeping" page with a button to wake it up. Cold-starting takes anywhere from 30 seconds to over a minute depending on your dependencies. Apps with heavy requirements.txt files (pandas, scikit-learn, plotly) take longer because pip installs everything fresh on each cold start.

One workaround that used to work: pushing a commit to the repo would trigger a redeploy and wake the app. As of April 2025, Streamlit changed this — pushing commits to the repo no longer wakes sleeping apps. The only way to wake an app is a visitor clicking that button.

There are also opaque resource limits. Community Cloud allocates up to 2.7 GB of RAM per app according to the Streamlit docs, though practical headroom is less after Streamlit's own runtime overhead. If your app exceeds available memory, it gets killed without a clear error message. Users in the forum report apps being terminated mid-session with no warning, sometimes repeatedly, with no indication of what limit was hit.

The combination of sleeping + resource limits + unclear error messages creates a pattern: the app works perfectly in development, works on Community Cloud for a demo, and then fails unpredictably once real people start relying on it.

This isn't Streamlit being careless. It's the economics of free hosting. AWS charges for every hour a container runs. Keeping thousands of rarely-visited apps alive 24/7 would cost real money that nobody is paying for.

The sleep is the price of free. Understanding that changes how you think about workarounds: you're not fixing a bug, you're fighting an economic constraint.

The workaround graveyard

The Streamlit forum is full of creative hacks to keep apps alive. Most of them work temporarily and then break.

UptimeRobot / Freshping pings. The idea: use a monitoring service to hit your app URL every 5 minutes, simulating a visitor. This keeps the app "active" and prevents the sleep timer from triggering. In practice, this worked when Community Cloud tracked HTTP requests as activity. Multiple forum posters report that Streamlit changed what counts as "activity" — a simple HTTP ping no longer reliably resets the sleep timer. The response is a 200 OK, so UptimeRobot shows "up," but the app still sleeps on schedule. Even when it works, you're consuming shared resources 24/7 for an app nobody is actually using, which is exactly the behavior the sleep mechanism exists to prevent.

Empty GitHub commits. Users discovered that pushing a commit to the repo used to trigger a redeploy, waking the app. So they set up GitHub Actions to push an empty commit every few hours. This no longer works — Streamlit stopped waking apps on new commits in April 2025. Even before that change, it was brittle: it polluted git history and triggered a full redeploy rather than a simple wake.

st_autorefresh or JavaScript keep-alive. Embedding a client-side timer that refreshes the page or fires an XHR request every few minutes. This only works while someone has the browser tab open — the moment they close it, the timer stops and the sleep countdown begins.

It also causes issues with st.session_state, since each auto-refresh can reset widget state depending on your app's structure. Users report losing form inputs, selected filters, and file uploads mid-session.

Cache TTL tricks. Setting st.cache_data TTL to force periodic re-execution. This doesn't prevent sleeping — the TTL only matters during active sessions. Once the app is asleep, no Python code is running, so no TTL fires.

Scheduled reboot via the dashboard. Some users manually reboot their app from the Community Cloud dashboard every morning before their team arrives. This works, but it requires a human to remember to do it every single day — and it still means a cold start when the reboot finishes.

The fundamental problem with all of these: you're fighting the platform's economic incentives. Community Cloud doesn't want your app running 24/7 for free. Any workaround that succeeds is a cost Streamlit didn't budget for, and they have every reason to close the loophole.

Several of the tricks above worked in 2024 and don't in 2026.

When the sleep actually matters

The sleep is perfectly fine for many use cases. If you're hosting a portfolio project, a demo for a blog post, or an internal tool that one person uses twice a week — the 30-second cold start is a mild annoyance, not a blocker.

The sleep becomes a real problem when:

You send a link to a client or stakeholder. They click it at 9am. They see "This app is sleeping. Click to wake up." They don't know what Streamlit is or why they should wait 45 seconds. They close the tab.

You never hear about it, because they don't email you to say "your link was broken" — they just move on. This is the most expensive failure mode: not a crash you can debug, but a silent loss of trust you never learn about.

Your app is a scheduled data product. You built a dashboard that your team checks every morning. The first person to arrive waits for the cold start. Worse, if the app loads data on startup (which most data apps do), the cold start includes re-running all your data queries. A 30-second boot becomes a 2-minute wait.

And if that first query hits a rate-limited API or a slow database, the cold start can time out entirely — showing the visitor an error after they already waited.

You embedded the app in another page. If your Streamlit app is iframed into a wiki, documentation site, or internal portal, the "sleeping" interstitial breaks the integration entirely.

The wake-up button doesn't work well in iframes, and even when it does, the experience is jarring — a Streamlit-branded interstitial inside your company's page.

Your app needs more memory. If you're loading a large dataset, running a model, or doing image processing, Community Cloud's 2.7 GB ceiling — minus Streamlit's own overhead — may not be enough. There's no way to request more resources on the free tier.

You're running multiple apps. Community Cloud limits the number of apps per account. If you have a portfolio of dashboards for different clients or teams, you'll hit the cap and have to choose which ones stay deployed.

There's no paid upgrade path on Community Cloud to raise the limit — the answer is always "deploy fewer apps."

Account blocked: the fair-use 403

Sleeping isn't the worst thing that can happen to your Community Cloud app. There's something worse: a 403 error that takes the app offline entirely.

Community Cloud enforces fair-use limits. If your app exceeds them — too many compute hours, too much bandwidth, or traffic patterns that look like abuse — your account gets blocked with a 403 error and the app stops serving entirely. Unlike sleeping, which resolves itself when a visitor clicks the wake button, a blocked app stays down until Streamlit support manually lifts the restriction.

There are 45 forum topics about this in the past 12 months, and GitHub issue #12524 tracks ongoing reports. The thresholds are not published. The block appears without warning, and the only resolution path is contacting Streamlit support and waiting for a response — which can take days.

What makes the 403 especially frustrating is that it often hits apps that are doing exactly what they're supposed to do: serving a dashboard that a team checks regularly, or handling a spike in traffic because a link got shared in a Slack channel. The behavior that triggers the block can look identical to legitimate use.

If you're running an app that matters to your work — one where a day of downtime means missed deadlines or a bad impression — this is the risk to weigh. The sleep is predictable: 12 hours of inactivity, then a wake button. A fair-use block is unpredictable and has no self-service recovery.

Your actual hosting options in 2026

Here's what's available. Pricing as of September 2026; check current pages for changes.

Streamlit Community Cloud (free). Best for demos, portfolios, open-source projects. Sleeps after 12h of inactivity. Up to 2.7 GB RAM (less in practice). No custom domains.

Authentication is GitHub-org-gated only — you can't add SSO, email-based access, or role-based permissions. If the person viewing your app doesn't have a GitHub account in your org, they can't get past the login. Zero cost, zero ops burden.

Self-hosted on a VPS (DigitalOcean, Hetzner, EC2). A $5-12/month droplet running Docker gives you full control. No sleeping, as much RAM as you pay for, custom domains via nginx.

The cost is ops burden: you're managing Docker, setting up HTTPS (Let's Encrypt + certbot), configuring nginx for WebSocket proxying, monitoring uptime, and handling security updates. Streamlit requires WebSocket support, and the default nginx config doesn't proxy WebSocket upgrades — this trips up almost everyone the first time.

If you have DevOps experience, this is a fine option. If you don't, you'll spend a weekend on it and then worry about it forever.

# The nginx WebSocket config that trips everyone up
location / {
    proxy_pass http://localhost:8501;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 86400;
}

AWS App Runner / Google Cloud Run / Azure Container Apps ($5-30/month). Managed containers without managing servers. Handle HTTPS and scaling for you. Cloud Run has cold starts by default (pay for "min instances" to avoid them), and configuring WebSocket support on all three requires non-obvious settings. App Runner is the easiest of the three for Streamlit because it handles WebSockets without extra config, but it's also the least flexible. You're building authentication yourself on all of them.

Railway / Render ($7-20/month). PaaS platforms that deploy from a GitHub repo. Railway starts at $5/month plus usage; Render's free tier sleeps like Community Cloud, but the $7/month tier stays alive. Both handle HTTPS and deploy-from-git.

Neither provides built-in authentication. You'd need to add streamlit-authenticator (a third-party library that stores credentials in a YAML file — fine for a side project, less so for a team) or put a reverse proxy with auth in front.

Heroku ($5-7/month for Eco dynos). Still works, but Heroku removed their free tier in 2022 and the platform has seen declining investment since the Salesforce acquisition. Eco dynos sleep after 30 minutes of inactivity — shorter than Community Cloud, ironically. The $7/month Basic dyno doesn't sleep.

WebSocket support works out of the box on Heroku, which is a genuine advantage over self-configuring nginx. But like Railway and Render, authentication is your problem.

Managed platforms with built-in auth. Platforms like Fastero host Streamlit apps with organization-level login — invite your colleagues by email and they sign in with their work account. No streamlit-authenticator hacks, no nginx reverse proxy. Apps get up to 16 GB RAM on compute tiers, with always-on hosting and custom domains. Paid plans start at $20/month.

A Streamlit app running in Fastero. Sample data.

Deploy from a GitHub repo and manage st.secrets in the UI instead of environment variables or YAML files. The trade-off is platform dependency, same as any managed service.

Picking the right option

The decision tree is simpler than it looks:

1. Is the app for public/demo use, and you don't care about cold starts? Stay on Community Cloud. It's free and the sleep is tolerable.

2. Do you need the app always-on, but you're comfortable with Docker and nginx? Self-host on a $6/month VPS. Total control, minimal cost, real ops burden.

3. Do you need always-on but don't want to manage infrastructure? Railway ($7/mo) or Render ($7/mo) are the simplest path. Add streamlit-authenticator if you need login.

4. Do you need auth and secrets management for a team? This is where managed platforms or a proper self-hosted setup with an auth proxy (like OAuth2 Proxy in front of nginx) makes sense.

5. Are you sharing apps with clients who shouldn't see your infrastructure? If the person viewing your app shouldn't have to know what Streamlit is, or click a "wake up" button, or create a GitHub account — you need a platform that handles auth and availability for you.

The one thing I'd avoid: spending hours rigging workarounds to keep Community Cloud apps alive. The sleep exists for a reason, the workarounds are fragile, and the alternatives start at $5-7/month. Your time is worth more than $7.

The bigger picture

Streamlit's core value proposition — "turn a Python script into a web app in minutes" — is genuine and powerful. The framework itself is excellent. The hosting gap exists because Community Cloud was designed as a showcase, not a production platform, and no amount of UptimeRobot pings changes that.

The good news is that the framework and the hosting are separate decisions. Your app.py runs on Community Cloud, on a VPS, on Railway, or on a managed platform with zero code changes. You're not locked in.

Start on Community Cloud for prototyping. Move when the sleep starts costing you — whether that cost is a client who closed the tab, a team that stopped trusting the dashboard, or a morning wasted debugging a 403.

If you're building data apps seriously, the framework choice (Streamlit vs Dash vs Gradio vs Panel) matters less than the deployment story. Whichever framework you pick, you need hosting that doesn't sleep when your users show up.

Try Fastero free — deploy from GitHub with auth built in, no cold starts. No credit card required.