We're investigating reports that bubble.io and the editor are not loading for users.

What to do

• Check whether you use Bubble in us. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 55m it lasted.

  Anything that failed between 2026-11-10 19:39 UTC and 2026-11-10 20:34 UTC may need a replay.

• Subscribe to Bubble's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=bubble works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Bubble 4

1. identifiedNov 10, 2026, 7:39 PM UTC

   We're investigating reports that bubble.io (http://bubble.io) and the editor are not loading for users. We are investigating a fix now.

   provider

2. identifiedNov 10, 2026, 8:02 PM UTC

   We have a fix for the discovered resource issue, rolling out changes now.

   provider

3. monitoringNov 10, 2026, 8:13 PM UTC

   The fix has been deployed and we're monitoring the applied fix.

   provider

4. resolvedNov 10, 2026, 8:34 PM UTC

   What happened At 9:00 AM ET on November 10 we shipped a change to how our servers cache data. A side effect was that our servers began requesting font data from Google far more often than before. Google caps how many of these requests we can make per day. That afternoon we hit that cap, and Google began rejecting our requests. Page loads that depended on that font data stalled or failed, and the failed requests were retried, which kept us pinned at the limit. Timeline (November 10, ET) - 2:10 PM: Google begins rejecting our font requests. Errors and slow page loads start. - 2:20 PM: First user reports appear on the forum. - 2:26 PM: Our monitoring alerts fire and engineers are paged. - 2:39 PM: We trace the problem to the 9:00 AM change and decide to roll it back. - 2:49 PM: We confirm the usage cap is the cause, ask Google for a higher limit, and begin provisioning separate capacity so we don't have to wait for that request. - 3:00 PM: The rollback is live. It does not restore service on its own, because we are still over the cap. - 3:08 PM: We find that our servers have not picked up the new capacity. We correct this and restart them. - 3:09 PM: Uptime checks pass again. - 3:15 PM: Errors have dropped off and we move to monitoring. What we're doing about it - The change that caused the increase has been rolled back. - We have provisioned additional capacity and asked Google for a higher limit. - We are changing how fonts are loaded so that page loads no longer depend on a request to Google. This work is in progress.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.