# Задержка подтверждения сбоя

Открытие инцидента только при непрерывной недоступности дольше выбранного времени — чтобы не реагировать на короткие сбои

> Индекс всей документации в markdown: https://statuser.cloud/llms.txt — там перечислены остальные статьи. Всё одним файлом: https://statuser.cloud/llms-full.txt. Документация API: https://statuser.cloud/api-reference.md

## Доступность по тарифам

Доступно в тарифе Team

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Задержка подтверждения сбоя | нет | нет | да |

Сравнение тарифов: https://statuser.cloud/pricing

## Через API и MCP

Описанное в статье можно сделать программно — запросом к публичному API или через MCP-сервер Statuser, который работает поверх того же API. Понадобится API-ключ, создать его можно на любом тарифе; ограничения тарифа в API те же, что в интерфейсе.

- Документация API: https://statuser.cloud/api-reference (машиночитаемо: https://statuser.cloud/api-reference.md)
- MCP-сервер: https://github.com/statuser-cloud/mcp

---

Обычно Statuser открывает инцидент и отправляет уведомление сразу, как только сервис признан недоступным. Иногда это лишнее: короткий сбой — сервис «моргнул» на одну проверку и тут же вернулся — не всегда стоит инцидента и уведомления. Задержка подтверждения сбоя позволяет открывать инцидент, только если сервис недоступен непрерывно дольше выбранного времени.

По умолчанию задержки нет — инцидент открывается на первой же неудачной проверке, как и раньше. Настройка доступна на тарифе **Team**.

## Как настроить

В продвинутых настройках монитора есть параметр **«Задержка подтверждения сбоя»** — ползунок от 0 (открывать сразу) до 1 часа. Выберите, сколько сервис должен непрерывно лежать, прежде чем Statuser откроет инцидент.

Настройка задаётся для каждого монитора отдельно и применяется к проверкам доступности: **HTTP/HTTPS**, **ключевое слово**, **TCP** и **Ping**.

## Как это работает

- Как только сервис перестал отвечать (проверка провалилась во всех выбранных регионах — см. [Ложные срабатывания](/docs/false-positives)), Statuser засекает время и запускает [учащённый мониторинг](/docs/fast-checking) — проверяет сервис чаще.
- Если к концу выбранной задержки сервис так и не восстановился — открывается инцидент и уходит уведомление.
- Если сервис вернулся раньше — инцидент не открывается, уведомления не приходят: короткий сбой остаётся незамеченным для алертов.
- Начало инцидента фиксируется по моменту **первого** сбоя, а не по моменту подтверждения. Поэтому длительность инцидента и статистика аптайма считаются честно, без «потерянных» на подтверждение секунд.

> Задержка влияет только на **открытие** инцидента. Восстановление фиксируется
> сразу, без задержки. А поскольку во время окна подтверждения работает учащённый
> мониторинг (проверки каждые 30 секунд), реальный сбой подтверждается быстро даже
> при большой задержке.

## Когда это полезно

- Сервисы с редкими короткими просадками (перезапуск воркера, деплой, кратковременная сетевая потеря), которые восстанавливаются за секунды и не требуют реакции.
- Проверки, где важнее не получить ложный алерт, чем узнать о сбое на минуту раньше.

## Где применяется

- Работает для проверок доступности: **HTTP/HTTPS**, **ключевое слово**, **TCP** и **Ping**.
- Не применяется к heartbeat, мониторингу SSL и домена, а также DNS-записей.

---

Источник: https://statuser.cloud/docs/incident-confirmation