Лимиты
Таймауты, лимиты запросов, тарифные квоты и другие ограничения, которые Triggo соблюдает во время выполнения.
Лимиты
Все ограничения, которые Triggo соблюдает во время выполнения, в одном месте. Значения ниже взяты прямо из кода исполнителя и биллинга — это не «планы», а реальность.
Таймауты выполнения
Оба таймаута прерывают текущую работу и записывают в журнал событие step_timed_out. Таймаут на уровне pipeline — жёсткий глобальный потолок, который нельзя поднять per workflow.
| Область | Значение | Константа в коде |
|---|---|---|
| Шаг (один узел) | 30 с (30 000 мс) | DEFAULT_STEP_TIMEOUT_MS |
| Pipeline (весь запуск) | 300 с / 5 мин (300 000 мс) | DEFAULT_PIPELINE_TIMEOUT_MS |
| Максимальный глобальный таймаут | 300 с (300 000 мс) | MAX_GLOBAL_TIMEOUT_MS |
Шаг, превысивший таймаут шага, падает с ошибкой TIMEOUT. Запуск, превысивший таймаут pipeline, прерывается независимо от того, какой шаг сейчас выполняется.
Лимиты запусков (на пользователя)
| Лимит | Значение |
|---|---|
| Запусков на пользователя в час | 100 |
| Окно | 3 600 000 мс (1 ч) |
| Атомарность | Redis Lua EVAL (атомарная проверка-инкремент) |
Когда пользователь превышает лимит, выполнение отклоняется без инкремента счётчика, а в связанный чат-тред один раз за окно на pipeline публикуется системное сообщение на русском: Превышен лимит запусков (100 в час). Выполнение возобновится через N мин.
Lua-скрипт гарантирует, что параллельные webhook-воркеры не смогут переступить лимит.
Структурные лимиты workflow
Проверяются при развёртывании и во время выполнения.
| Лимит | Значение | Константа в коде |
|---|---|---|
| Макс. узлов в workflow | 500 | MAX_WORKFLOW_NODES |
| Макс. связей в workflow | 1000 | MAX_WORKFLOW_EDGES |
| Макс. глубина вложенности Loop | 3 (от 0; 0 = верхний уровень) | MAX_LOOP_NESTING_DEPTH |
Workflow, выходящие за эти пределы, отклоняются при сохранении/развёртывании.
Предохранитель (на интеграцию)
Защищает сторонний API от дальнейших запросов после повторных сбоев. Состояние хранится в Redis и общее для всех workflow, использующих одну и ту же интеграцию.
| Параметр | Значение |
|---|---|
| Порог сбоев | 5 сбоев |
| Окно сбоев | 300 с (5 мин) |
| Время остывания (разомкнут) | 60 с |
См. Обработка ошибок для семантики восстановления и работы half-open-зондов.
Авто-пауза (на pipeline)
После 3 подряд упавших запусков pipeline останавливается. Отслеживается через Redis-ключ autopause:{pipelineId}:failures. Успешный запуск сбрасывает счётчик.
См. Обработка ошибок, чтобы узнать, как снова включить приостановленный pipeline.
Тарифные квоты
Запросы runtime API и MCP, аутентифицированные Bearer API-ключом, ограничиваются per ключу через Redis ZSET-скользящее окно. Квоты API-ключей (активных ключей на аккаунт) проверяются при создании ключа.
| Тариф | Runtime API (req/мин) | Активных API-ключей |
|---|---|---|
free | 60 | 1 |
starter | 300 | 3 |
pro | 1 000 | 10 |
business | 1 000 | неограниченно |
Неизвестный или отсутствующий тариф откатывается к 60 req/мин. Размер окна — 60 с, точный — никаких burst-разрешений сверх устойчивой скорости.
Каждый runtime-ответ несёт заголовки лимитов (x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset как epoch seconds); 429-ответы также содержат retry-after (секунды).
См. Лимиты агента для точного контракта заголовков и Billing, чтобы поднять тариф.
Смотрите также
- Обработка ошибок — повторы, continue-on-failure, предохранитель, поведение авто-паузы
- Отладка запусков — осмотр таймаут-нутых или rate-limit-нутых запусков в журнале
- Лимиты агента — заголовки runtime API и MCP