Fede from the Community team here. Heads up: Bubble will be briefly offline from 11:30–11:40 PM EDT on September 13, 2025 for scheduled shared cluster database maintenance. This will affect both editor and runmode operations. This won’t affect your existing app data.
We apologize for any inconvenience this may cause.
Fede and the Bubble Team
FAQs
What does “offline” means exactly?
Anything that runs on Bubble will be inaccessible during this brief maintenance window
Examples: you won’t be able to access the Bubble editor, and your live apps will be inaccessible as well
What happens if my apps are in the middle of something when maintenance starts?
Your operations will pause and restart after maintenance.
Data will remain in the state it is when downtime begins
For extra guarantees you could also opt to pause on your own before maintenance
Will Bubble show some sort of static maintenance page to my users?
No, Bubble as a whole will be inaccessible.
If you want/need one, there are ways you can plan for a maintenance page to show during this brief downtime window
For creating a static maintenance page during Bubble downtime, you’ll typically need to use external services since your Bubble app won’t be accessible. Popular options include:
CDN services like Cloudflare, which can serve static pages when your origin server is down
Static hosting platforms like Netlify, Vercel, or GitHub Pages for hosting simple HTML maintenance pages
DNS-level solutions that can redirect traffic to a maintenance page hosted elsewhere
Load balancers or reverse proxies that can detect when your Bubble app is down and serve alternative content
Another common question will be what happens to backend workflows called via webhooks during the downtime (e.g related to Stripe billing). Will they fail? I would assume they do, but would be great to clarify.
Will workflows that are scheduled to run during the maintenance delay until after (as if the scheduler was paused), or attempt to run and error?
If Stripe webhooks fail, it won’t be an issue. Stripe always perform retries, and chances are even the first retry will happen after the maintenance window has passed.
Other webhooks that won’t do retries .. that’s a valid question.
Webhooks will go as undelivered from stripe (if they happen during this 10 minutes), which will cause stripe to try them again immediately, then again some time later, then again hours later. Stripe will retry until the data is synchronized. You’ll (we’ll) be ok.
Be thankful you went the extra mile to do everything properly with webhooks. This is exactly why they exist.
Curious about this as well. In the past any database downtime would nuke scheduled WF’s in that scheduled time and there was no way for the app to re-run them or even a way to know which WFs didn’t succeed
the DB upgrade happening Sept 13 is technically “instantaneous”, but it takes about 20-45 seconds to get back up fully. During that time, Bubble will be provisioned to retry any workflows and, if everything goes correctly, you should not be able to tell that they had to try for a few seconds before working.
If they were scheduled to run exactly in the moment Bubble db goes down, they’ll be delayed. If it was a long workflow that happens to be running in the moment the db goes down, it’ll retry.
This is the last I had heard Bubble’s response on this:
I completely understand your concern regarding scheduled workflows, especially in light of the recent downtime. I want to clarify that Bubble does attempt to re-run any scheduled workflows that occur during brief database or main cluster outages. When there is a short downtime, for example, the database goes offline for a few seconds, our procedure retries any queries that were affected during the crash. However, in rare instances, a very small number of these queries might not be retried successfully.
That being said, if the database or main cluster experiences an extended outage (for longer than a few seconds) the workflow will likely fail. In such cases, please don’t hesitate to reach out to our team. We’ll do our best to provide more details on which workflows were affected and help troubleshoot further.
Our engineering team is actively working to improve this process, and we are keeping a running list of all occurrences to maintain transparency with our users.
That said, I want to emphasize that this situation is extremely rare, and our retry procedure for queries after brief outages is generally very reliable. If you experience any issues following a more major outage, please don’t hesitate to reach out to us.
