Cloudflare запустила Spend Management у бета-версії: клієнти з оплатою за використання можуть задавати ліміти для Workers і Durable Objects та призупиняти частину операцій після досягнення порога. Анонс вийшов 13 листопада. Це корисний контроль для власників застосунків, проте він має два важливі наслідки: спрацьовує із затримкою й може зупинити одразу кілька сервісів одного акаунта.
Спочатку визначте, яку витрату обмежуєте
Workers виконують код застосунку, а Durable Objects надають окремі обчислення та стан. Spend Management рахує витрати за продуктом у поточному періоді підписки. У Workers до ліміту входять запити й процесорний час після врахування включеного використання. Фіксована плата за підписку та інші продукти оплачуються окремо.
Отже, суму в полі ліміту зручніше читати як контроль конкретної статті витрат. Перед налаштуванням відкрийте поточне використання та випишіть, які продукти задіяні в застосунку. Для невеликої форми це може бути один Worker; для ШІ-помічника — Worker, сховище, база та зовнішній модельний API.
У Billing → Billable Usage розрізняйте Total usage, загальне використання з включеним обсягом, і Billable usage, оплачувану частину понад нього. Поле Usage cost показує витрати продукту за вибраний період. Такий перегляд допоможе перенести в бюджет грошову суму, а не кількість запитів.
Приклад: один акаунт, робочий сайт і експеримент
Уявімо акаунт із Worker для робочого сайту та тестовим ботом. Наведені суми вигадані й потрібні для пояснення механізму. У поточному періоді вже записано такі витрати:
| Стаття | Умовна сума | Входить у ліміт Workers |
|---|---|---|
| Запити й CPU всіх Workers акаунта | $48. | Так. |
| Використання Durable Objects | $12. | Має окремий контроль. |
| Інші продукти, наприклад R2 | $8. | Оплачуються окремо. |
| Фіксована підписка | За чинним тарифом. | Виключена з цього ліміту. |
Якщо поставити Workers-ліміт $60, уже витрачені $48 становитимуть 80% порога. Запас у межах цього розрахунку — $12. При цьому ліміт діє на всі Workers акаунта: активність тестового бота може призвести до блокування й робочого Worker. Окремо врахуйте залежності між ними: форма на сайті може звертатися до іншого сервісу, який теж стане недоступним.
Ліміт $60 також не означає підсумковий рахунок на $60. У прикладі вже є $20 інших витрат, до яких додадуться підписка, подальше використання та можливе перевищення під час затримки блокування. Таке розділення корисніше за один загальний напис «бюджет»: воно показує, які саме компоненти ви контролюєте.
Як задати ліміт у панелі
- Відкрийте Billing → Spend Management потрібного акаунта.
- У рядку Workers або Durable Objects виберіть Edit the spending limit.
- Введіть додатну суму в Monthly limit (USD) і збережіть через Save limit.
- Перевірте стан On. Новий ліміт умикається під час збереження; редагування наявного зберігає його попередній стан увімкнення.
Ліміт враховує вже записане використання. Якщо у нашому прикладі з $48 поставити поріг $30, це не дасть ще $30 на майбутнє: умова вже виконана й пауза може початися після оцінки політики. Тому перед натисканням Save перевірте поточну суму та період, до якого вона належить.
Сповіщення та блокування — окремі рішення
Можна налаштувати лише повідомлення або контроль із призупиненням операцій. Для отримання листів потрібна адреса одержувача: документація попереджає, що збереження ліміту в панелі не додає її автоматично. Для політики з адресою передбачені повідомлення на 80% і 100%; різкий стрибок між оцінками може дати лише друге.
Налаштування політик і повідомлень також доступне через cf CLI. Довідка описує перегляд списку політик, додавання або зміну адреси сповіщень і журнал подій. Після налаштування перевірте збережену адресу та обраний тип дії. Наявність слова On у статусі означає ввімкнену політику, а не підтвердження, що застосунок зараз відповідає.
Що станеться після спрацьовування
Після застосування Workers-ліміту блокуються нові виклики, зокрема HTTP-запити, Cron Triggers та обробники черг. HTTP-відвідувач може побачити помилку 1103; вона має й інші причини, тому спершу перевірте стан у Billing. Статичні файли, що обслуговуються без виконання Worker, можуть залишатися доступними.
Для Durable Objects є окремі обмеження. Блокування стосується нових запитів і низки операцій зі сховищем, але вже відкриті WebSocket-з’єднання та деякі операції можуть продовжувати роботу. Збережені дані лишаються на місці й можуть далі створювати витрати. Перед використанням цього контролю перевірте довідку саме свого типу сховища та фонових завдань.
У блозі Cloudflare описує облік із затримкою до десяти хвилин і асинхронне поширення блокування. Звідси практичний висновок: залишайте запас між бажаними витратами й максимально прийнятним для вас рахунком. Підсумкові нарахування звіряйте з рахунком, а оцінку в панелі використовуйте для спостереження за тенденцією.
План відновлення варто записати заздалегідь
Щоб зняти саме це блокування, можна підняти поріг вище поточних витрат, вимкнути або видалити політику. Зміни також потребують часу. Перемикання Off і On не обнуляє накопичену суму. Новий період починається за циклом підписки, наприклад 18-го числа, а не обов’язково першого числа місяця.
Для нашого вигаданого акаунта зручно записати чотири речі: хто читає повідомлення, які сторінки перевірити при паузі, хто може змінити поріг і за якою ознакою вважати роботу відновленою. Після зміни налаштування перевірте реальну дію застосунку — наприклад, відправлення тестової форми — та журнал причин зростання витрат. Самого повернення статусу недостатньо для оцінки всього процесу.
Якщо застосунок викликає ШІ-моделі, витрати на них потребують окремого контролю: AI Gateway має власні бюджети для запитів, що проходять через нього. Загальний план зручніше будувати зі списку всіх компонентів. Приклад такого розбору сервісу є в матеріалі про прототип із Google Maps у AI Studio, де важливо розрізняти демонстраційний доступ і реальні API-виклики.
Долучайтеся до розмови
Пишіть по суті й поважайте інших читачів. Перший коментар може з’явитися після перевірки редакцією.