bubble.io is down чи зламав я: як за 15 хвилин відокремити інцидент платформи від власної помилки

Ситуація знайома. MVP зібраний на no-code і швидкому вайбкодингу. Лишилося показати його першим користувачам або надіслати демо ангельському інвестору. Відкриваєш застосунок, тиснеш ключову кнопку, і нічого не відбувається. Або замість сторінки білий екран і системна помилка.

У голові соло-фаундера одразу одне питання: це інцидент платформи, чи я сам щось зламав останнім кліком у редакторі? Схожий розбір: Інцидент workflows 23 вер.: мінімальний.

Найгірше, що можна зробити в цю хвилину, це гарячково видаляти воркфлоу, переписувати структуру бази даних або відкочувати налаштування, які працювали. У паніці легко зламати те, що насправді працювало ідеально.

Тому я ставлю таймер на 15 хвилин і спокійно йду деревом рішень. Нічого не правлю, поки не зрозумію, де корінь проблеми.

Хвилини 0–3: Визначте смугу симптому та перевірте статус платформи

У налаштування я поки не лізу. Спершу відношу симптом до однієї з трьох смуг:

Смуга редактора та доступу: не відкривається редактор застосунку чи особистий кабінет, або не вдається авторизуватися на платформі.
Смуга доступності застосунку (Run-mode): опублікована сторінка або прев’ю не завантажуються зовсім. Білий екран, помилка 500, таймаут браузера.
Смуга логіки та даних: сторінка відкривається, інтерфейс рендериться, але конкретна дія (кнопка, фільтр у таблиці, запис у базу) не спрацьовує або показує порожнечу.

Якщо це перша чи друга смуга, я одразу відкриваю офіційний bubble.io status на https://status.bubble.io/. Статус також видно в діалозі створення баг-репорту через вбудований чат-бот у редакторі. Схожий розбір: Bubble MCP: контрольний список першого.

Дивлюся на окремі компоненти інфраструктури:

Main Bubble Environment (головний спільний кластер додатків);
Bubble Editor (робота самого редактора);
Bubble Dedicated (якщо застосунок на виділеному корпоративному інстансі);
Application Dependencies (критичні залежності інфраструктури: AWS, Cloudflare тощо).

Нюанс: блок «Application Dependencies» показує базових провайдерів самого Bubble. Стан ваших сторонніх сервісів він не відстежує, тобто ні платіжного шлюзу, ні OpenAI, ні сервісу розсилки листів.

Якщо на сторінці статусу висить активний інцидент саме у вашому компоненті, припиняйте редагувати застосунок. Я в такому разі пишу користувачам сповіщення і чекаю, поки інженери платформи його розв'яжуть.

Хвилини 3–6: Development проти Live та перевірка останнього деплою

Статус зелений? Тоді з'ясовую межі збою: ламається тестова гілка (version-test) чи живий домен (Live)?

Якщо збій тільки на Live:

Згадую, коли був останній деплой. Якщо я щойно розгорнув оновлення, перше питання: чи оновили користувачі відкриту вкладку. Після деплою клієнтський застосунок у старій вкладці може звертатися до старої версії скриптів або до полів, які я вже змінив. Помилки тримаються, доки сторінку не перезавантажать повністю.
Відкриваю Version Control -> Changelog. Технічна освіта тут не потрібна. Журнал змін показує за категоріями, хто, що і коли редагував. Історія зберігається обмежений час, залежно від плану: від 14 днів на Growth до 1 року на Dedicated Enterprise. Якщо після деплою все пішло шкереберть, завжди можна повернутися до попереднього сейвпоінта (Savepoint) або на конкретний момент часу.
Враховую Issue Checker. Цей вбудований модуль Bubble блокує деплой, якщо ви забули заповнити обов'язковий вираз або зламали зв'язок між полями. Отже, якщо Live розгорнувся успішно, грубих структурних помилок конфігурації там немає. Шукати треба в динамічній поведінці даних.

Хвилини 6–9: Безпечний режим (Safe Mode) та локальне середовище

Помилка відтворюється і в Development? Наступні підозрювані: сторонній код і браузерні розширення.

Відкриваю сторінку в інкогніто з вимкненими блокувальниками реклами та скриптів (AdBlock, uBlock, Privacy Badger). Блокувальники часто обривають виклики аналітики або плагінів, і сторінка зависає на завантаженні.
Запускаю Safe Preview. Для діагностики в Bubble це чудовий інструмент. Затискаю кнопку Preview або вибираю безпечний перегляд у випадаючому меню. Варіанти:
- вимкнути кастомний HTML на сторінці;
- вимкнути плагіни (зокрема ком'юніті-плагіни);
- вимкнути і HTML, і плагіни одночасно.

(Залежно від вибраного режиму базові плагіни від команди Bubble можуть лишатися увімкненими, а користувацькі сторонні плагіни вимикаються повністю.)

Якщо в безпечному режимі сторінка одразу завантажилась і кнопка спрацювала, з платформою Bubble все гаразд, і база даних ціла. Збій дає конфліктний JavaScript-код зовнішнього плагіна або фрагмент коду, доданий через елемент HTML.

Хвилини 9–12: Privacy Rules — невидима пастка для даних

Найчастіший кошмар соло-фаундера звучить так: «Учора мої таблиці й картки відображалися, а сьогодні Repeating Group порожній! Bubble зламав мені базу даних!»

У 9 випадках із 10 база ціла. Причина в правилах приватності (Privacy Rules).

Правила приватності в Bubble виконуються суворо на сервері. Якщо поточний сеанс користувача не проходить умову правила, сервер Bubble навіть не надсилає відповідні поля в браузер. Інтерфейс виглядає робочим, а дані просто не приходять.

Я перевіряю дві речі:

Правила приватності не оновлюються самі на вже відкритій сторінці. Змінили права чи статус користувача і не перезавантажили сторінку — бачите порожнечу.
Запускаю «Preview as» / «Run as». У вкладці Data -> App Data знаходжу потрібного користувача і запускаю прев’ю від його імені. Якщо під адміністратором дані видно, а під тестовим клієнтом ні, проблема в моєму налаштуванні Privacy Rule для цього типу даних. Сервер тут ні до чого.

Хвилини 12–15: Логи сервера (Server Logs) та зовнішні API

Сторінка працює, права налаштовані, але після кліку процес нескінченно «висить» або вилазить червоне повідомлення про помилку. Тоді так:

Вмикаю Debugger. В адресному рядку тестової версії має стояти параметр debug_mode=true. Коли дія падає під час виконання, на панелі налагоджувача з'являється червона іконка помилки виконання (execution error). Вона прямо вказує на крок воркфлоу, який дав збій.
Дивлюся Server Logs. У редакторі відкриваю Logs -> Server Logs, обираю середовище (Development або Live) і виставляю точний проміжок за останні хвилини. Фільтри:
- HTTP request/response — показує, чи відповів зовнішній сервер;
- Plugin server-side error — ловить падіння плагіна на бекенді;
- Workflow error — виділяє перервані дії.
Перевіряю API Connector. Якщо воркфлоу звертається до стороннього сервісу, наприклад генерує текст через LLM або створює рахунок, я відкриваю кабінет цього провайдера. Чи не вичерпався ліміт токенів? Чи дійсний API-ключ? У налаштуваннях викликів API Connector я вмикаю опцію «Include errors in response…». Тоді при падінні стороннього сервісу застосунок не зависає, а користувачеві можна коректно показати дружнє попередження.

Підсумкове дерево рішень за 15 хвилин

Коли немає часу перечитувати довгі мануали, я йду цим маршрутом:

0–3 хв: Чи відкривається редактор і чи зелений статус? Якщо на status.bubble.io аварія, видихаю і чекаю.
3–6 хв: Ламається тільки Live після свіжого деплою? Прошу оновити сторінку, дивлюся Changelog і за потреби повертаюся до Savepoint.
6–9 хв: Чи працює сторінка в інкогніто та в Safe Preview без плагінів? Якщо так, шукаю проблемний плагін і вимикаю його.
9–12 хв: Пропали тільки дані? Оновлюю сторінку і тестую Privacy Rules через «Run as».
12–15 хв: Кнопка зависає? Шукаю червону іконку в Debugger, фільтрую Server Logs за помилками і перевіряю баланс та доступ до стороннього API. Схожий розбір: Аутідж BubbleGo: що реально зачепило,.

Незалежний соло-фаундер чи початкуючий bubble io developer не має витрачати години на паніку. Мені чекліст береже нерви й робочу базу, а запуск не втрачає швидкості.

Шаблон повідомлення для перших користувачів та інвесторів

Якщо під час відкритого тестування з'ясувалося, що проблема справді на боці платформи або стороннього провайдера, не мовчіть і не виправдовуйтеся. Я надсилаю коротке, впевнене повідомлення в чат підтримки чи на пошту:

«Вітаю! Я зафіксував тимчасові труднощі з [завантаженням списку / створенням запиту] через технічні роботи на рівні інфраструктурного провайдера [назва провайдера або платформи]. Ваші збережені дані в повній безпеці. Я стежу за ситуацією і повідомлю, щойно сервіс відновить штатну роботу. Наступне оновлення статусу надішлю найближчим часом. Дякую, що тестуєте ранній реліз!»