Your incident response is a support ticket
When a Bubble app breaks at 2am, the runbook has one step: file a bug report. Bubble's documentation is honest about what happens next. It says setting an exact timeline for a fix is difficult, then lists the reasons, ending with the one that lands hardest: some fixes wait for a scheduled deployment window. You are not on call for your own product. Someone at the vendor is, and you are in their queue.
The escalation path ends at a form
Airtable's support page, checked today, explains how to reach a human: open your home screen, click the question mark, click Message support. It publishes no response time. Webflow sells the response time instead. Priority support shows up on the Team plan at $2,500 a month with an annual contract required, and enhanced SLAs sit above that on Enterprise at a price you negotiate. If you run a Webflow site on Basic at $15 a month or Premium at $25, your support is whatever it turns out to be that week.
I do not think any of that is unfair. Running support costs money and tiering it is ordinary. What I want you to notice is the shape of what you buy. A faster SLA buys the right to be answered sooner. It does not buy the ability to act. Even at two hours, the fix belongs to the vendor's release calendar, and you spend the gap writing updates to people who assume you can do something.
Bubble asks you to work before you are allowed to hand the problem over. Reproduce the issue so it is not a one-off. Check the status page. Check the docs in case the behaviour is intended. Disable your plugins and third-party integrations to rule them out. That is a real debugging session, done by you, on your own time. At the end of it your reward is a ticket number.
Uptime you can measure and cannot change
Bubble's status page is better than most. It reports 99.85% uptime for the Main Bubble Environment over the window it currently covers, 99.92% for the editor, and 99.77% for Dedicated. Those are respectable figures for a platform hosting millions of apps. Run the arithmetic on a three-month window and 99.85% is roughly three hours in which your app was down and your only available move was pressing refresh on somebody else's page.
The part that gets me is the symmetry. During your own outage you hold exactly the information a stranger holds. No logs beyond what the platform exposes, no process list, no way to tell whether the problem is yours or theirs until the vendor says so in public.
That same status page lists what Bubble runs on: AWS in us-west-2, imgix, SendGrid, Cloudflare, Intercom. Publishing the dependency list is a courtesy and I wish more vendors did it. It is also a quiet inventory of decisions made for you. If SendGrid has a bad morning, your transactional email has a bad morning, and swapping providers is not a conversation you get to have.
What changes when the code is yours
Stay World Class ran on Webflow and Xano before we moved them to Next.js, NestJS and Supabase. The headline numbers were performance: Lighthouse went from 55.91 to 91 out of 100, and largest contentful paint came down 77%. We got there by reading the code that was slow and changing it, which is the whole trick. A four-stage ETL carried the legacy identifiers across into PostgreSQL UUIDs so nothing lost its history on the way.
The same property applies at 2am. A stack trace names a file and a line. You read it, you push, the deploy goes out in minutes because the deploy is yours. Nobody classifies your severity for you, and no fix waits on a release window set by a company that has never heard of your business.
The honest cost is that the pager becomes yours too. Owning the stack means somebody on your side answers when it breaks, including the breaks you caused. You are trading a queue you cannot influence for a responsibility you cannot delegate, and that is a genuine trade, not an upgrade.
When the ticket is the right answer
If your app is internal, or a few hours of downtime a quarter costs you an apology rather than revenue, stay where you are. Someone has to carry a pager rota and that someone has a salary. Three hours of downtime a quarter is cheaper than a hire, and pretending otherwise would be sales talk.
The same goes if nobody on the team reads stack traces. Owning the stack when you cannot debug it leaves you with an outage you still cannot fix, minus the vendor who was at least trying. That is worse than the queue, not better.
What tips it is money per hour. Once an outage costs more than the engineering capacity to respond to one, the ticket stops being a support channel and starts being the thing standing between you and your own product. Work out what an hour of downtime actually costs you. If the number is small, close this tab with a clear conscience.
