# Statuser — документация

> Полный текст документации Statuser: 42 статьи. Отдельная статья доступна как `https://statuser.cloud/docs/<slug>.md`, краткий индекс — https://statuser.cloud/llms.txt

## Содержание

- **Быстрый старт**
  - С чего начать
- **Мониторинг**
  - Добавление сервера в мониторинг
  - Виды мониторинга
  - Heartbeat мониторинг
  - Мониторинг медленных ответов
  - Мониторинг SSL и домена
  - Мониторинг реестра РКН
  - Типы DNS записей
  - Ложные срабатывания
  - Учащённый мониторинг после сбоя
  - Задержка подтверждения сбоя
  - User-Agent и IP-адреса для проверок
  - Используемые DNS
- **Инциденты**
  - Создание инцидента
  - Диагностика инцидента
  - Комментарии к инциденту
  - Коды ошибок
  - Установка Netcat
- **Нотификации**
  - Каналы уведомлений
  - Уведомления в Телеграм
  - Уведомления в MAX
  - Уведомления на емейл
  - Webhook-уведомления
  - Еженедельные отчёты
  - Режим праздников
- **Страницы статуса**
  - Создание страницы статуса
  - Сервера и группы на странице статуса
  - Кастомизация страницы статуса
  - Публичность и доступ
  - Интерфейс для посетителей
  - История инцидентов для посетителей
  - Плановые работы
  - Объявления
  - Подписчики
  - Публикация и ведение отчётов
  - Виджет статуса
- **Биллинг**
  - Тарифы и лимиты
  - Смена тарифа
  - Способы оплаты
  - Оплата по счёту для юридических лиц
  - Оплата не выполнена
- **Публичный API**
  - Управление API ключами

# С чего начать

Быстрый старт со Statuser

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

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

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

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

---

Statuser — это сервис, который позволяет выполнять проверки доступности различных сервисов в сети, включая серверы, сайты и приложения. Он поддерживает различные виды проверок и позволяет гибко настроить мониторинг для вашего бизнеса или проекта.

В этой документации вы найдете руководства и советы по быстрому старту, настройке и использованию Statuser для вашего проекта.

Поддерживаются следующие виды проверок:

- Пинг сервера.
- Проверка доступности по HTTP/HTTPS.
- Проверка любых TCP портов и доступности служб на сервере.
- Мониторинг ключевых слов в ответах.
- Heartbeat мониторинг (входящие запросы от ваших задач/сервисов).
- Мониторинг медленных ответов и уведомления о деградации времени ответа.
- Мониторинг изменений DNS-записей.
- Отслеживание даты окончания SSL-сертификата.
- Отслеживание даты окончания регистрации домена.

Вы можете легко настроить уведомления, чтобы получать оповещения по электронной почте, в Телеграм, MAX или в ваш вебхук при изменении статуса проверяемых сервисов.

## Руководства для быстрого старта

- [Как добавить сервер](/docs/add-server) — Инструкция по добавлению в Statuser первого сервера

- [Виды мониторинга](/docs/monitoring-types) — Какие проверки доступны и чем они отличаются

- [Мониторинг SSL и домена](/docs/ssl-domain-checks) — Следить за сроком действия SSL-сертификата и регистрации домена

- [Каналы уведомлений](/docs/notification-types) — Доступные виды нотификаций и их настройка

---

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


# Добавление сервера в мониторинг

Пошаговая инструкция по добавлению сервера в мониторинг

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Количество серверов в мониторинге | 5 серверов | до 50 серверов | до 500 серверов |
| Частота проверки | от 5 минут | от 1 минуты | от 1 минуты |
| Количество регионов проверок | 2 региона | 5 регионов | 5 регионов |
| Мониторинг ключевых слов | нет | да | да |
| Heartbeat мониторинг | нет | да | да |
| Мониторинг DNS | нет | да | да |
| Мониторинг SSL | нет | да | да |
| Мониторинг домена | нет | да | да |
| Выбор конкретных регионов | нет | да | да |
| Свои коды успешного ответа | нет | да | да |

Форма добавления одинаковая на всех тарифах, но часть типов мониторинга и продвинутых настроек в ней доступна не везде: на Free это HTTP/HTTPS, Ping и TCP.

Сравнение тарифов: 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

---

Для добавления нового сервера в мониторинг нажмите **Добавить** в разделе **Серверы**.

Большинство полей в форме создания уже будет предзаполнено значениями по умолчанию, но вы можете изменить любое из них:

1.  Выберите тип мониторинга: **HTTP/HTTPS**, **Ping**, **Порт TCP**, **Поиск текста** или **Записи DNS**.

    Подробнее о доступных типах и особенностях их работы можно узнать в статье [Виды мониторинга](https://statuser.cloud/docs/monitoring-types).

2.  Укажите хост.

    В поле **Хост** введите адрес сервера, например: **http://example.com** или **192.168.100.1**.

> Для доменов поддерживается формат IDN (Internationalized Domain Name). Это означает, что можно добавлять домены на любом языке, например, русском, китайском или арабском, а также использовать эмодзи в названии.

3.  В зависимости от выбранного типа мониторинга может потребоваться дополнительная настройка:

    - Для **HTTP/HTTPS** — выбрать HTTP метод (HEAD, GET, OPTIONS, POST, PUT, PATCH)
    - Для **Поиска текста** — выбрать HTTP метод (GET, POST, PUT, PATCH), указать текст и режим проверки
    - Для **TCP** — указать номер порта
    - Для **DNS** — выбрать типы записей для мониторинга (A, AAAA, CNAME, NS, MX, TXT, SRV, PTR, SOA)
    - Для **Heartbeat** — настроить ожидаемый интервал и допустимую задержку

    Подробнее об этих настройках можно узнать в статье [Виды мониторинга](https://statuser.cloud/docs/monitoring-types).

4.  Настройте интервал проверки.

    Поддерживаются интервалы от **1** минуты до **1** часа. Вы можете выбрать один из предустановленных вариантов или ввести свое значение.

5.  Укажите название сервиса (необязательно).

    Название сервиса **не влияет** на мониторинг, но позволяет удобно организовать список серверов.

6.      Выберите регионы, из которых будут выполняться проверки.

    Для всех видов мониторинга, кроме DNS, укажите одну или несколько географических локаций.
    По умолчанию выбраны все доступные регионы, но вы можете настроить список самостоятельно.

> Не рекомендуется выполнять проверки только из одного региона — это может
> привести к ложным срабатываниям при кратковременных проблемах в конкретной
> локации. Для надёжности рекомендуется выбрать хотя бы два региона.

7.  Настройте продвинутые параметры.

    Для проверок с помощью HTTP/HTTPS, поиска текста и мониторинга изменений записей DNS доступен контроль SSL-сертификата и домена. Подробнее об этом в статье [Мониторинг SSL и домена](https://statuser.cloud/docs/ssl-domain-checks).

    Для **HTTP/HTTPS** и **Поиска текста** на тарифах **Pro** и **Team** можно указать собственный список **кодов успешного ответа** — конкретные коды (например, `301`, `409`) или маски `2xx`, `3xx`, `4xx`, `5xx`. По умолчанию успешным считается любой код из диапазона `2xx`.

    Для всех видов мониторинга, кроме DNS, можно указать время ожидания ответа от сервера от **1** секунды до **30** секунд (по умолчанию 10 секунд).

> Чем меньше таймаут, тем раньше сайт будет помечен как неработающий, но при
> этом выше шанс ложного срабатывания.

8.  Запустите мониторинг, нажав кнопку **Начать мониторинг**.
    После этого сервер будет добавлен в список мониторинга и будут запущены проверки.

---

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


# Виды мониторинга

Доступные типы проверок в Statuser

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Мониторинг HTTP | да | да | да |
| Мониторинг Ping | да | да | да |
| Мониторинг TCP портов | да | да | да |
| Мониторинг ключевых слов | нет | да | да |
| Мониторинг DNS | нет | да | да |
| Heartbeat мониторинг | нет | да | да |
| Свои коды успешного ответа | нет | да | да |
| Уведомления о медленных ответах | нет | да | да |

HTTP/HTTPS, Ping и проверка TCP-порта работают на всех тарифах. Поиск текста, мониторинг DNS-записей и heartbeat подключаются начиная с тарифа Pro.

Сравнение тарифов: 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 доступны несколько видов мониторинга, которые можно использовать для проверки доступности сервисов или контроля записей DNS.
Каждый из них хорошо подходит для различных сценариев и позволяет гибко настроить мониторинг для вашего проекта.

> Для каждого типа проверки требуется указать хост. Если для проверки требуется
> IP-адрес, а был указан домен, то мы выполним DNS-запрос и используем
> полученный IP-адрес А-записи.

## Пинг

Пинг это один из самых простых способов проверки доступности сервиса. Он использует для проверки доступности сервиса протокол **ICMP** и позволяет проверить доступность сервера или устройства в сети.

Стоит учитывать, что пинг позволяет проверить только доступность сервера, но не работу конкретного сервиса на нем. Если сервер доступен, но сервис на нем не работает, то пинг все равно вернет успешный результат.

Для проверок доступности запущенного на сервере сервиса стоит использовать другие типы проверок, например, проверку с помощью **HTTP запросов** или проверку **TCP порта**.

## HTTP/HTTPS

Проверка с помощью **HTTP запросов** позволяет проверить работу веб-сервера и доступность сайта или API. По умолчанию успешным считается ответ с любым кодом из диапазона **2xx**.

По умолчанию для проверок используется метод **HEAD**, так как он наиболее производительный и минимально нагружает сервер. Но также можно выбрать другой метод, также поддерживаются **GET**, **POST**, **PUT**, **PATCH**, **OPTIONS**.

В продвинутых настройках на тарифах **Pro** и **Team** можно задать собственный список кодов, которые будут считаться успешными — например, добавить **301** или **409**, или использовать маски `2xx`, `3xx`, `4xx`, `5xx`. Если ответ сервера не попадёт ни под один из указанных кодов, проверка будет помечена как неудачная с ошибкой **Код ответа не входит в список успешных**.

> Для проверок **HTTP/HTTPS** (а также для **Поиска текста** и **TCP**) можно включить уведомления о медленном ответе — когда время ответа устойчиво превышает заданный порог.
> Подробнее о принципах работы этого вида мониторинга в статье [Мониторинг медленных ответов](/docs/slow-response-monitoring).

## Поиск текста (Keyword)

_Доступно в тарифах Pro и Team_

Этот тип мониторинга выполняет HTTP‑запрос (как HTTP/HTTPS), получает тело ответа и проверяет, содержится ли в нём указанный текст.

Доступны два режима:

- **Успех, если текст есть** — проверка успешна, если текст найден в ответе
- **Успех, если текста нет** — проверка успешна, если текст **не** найден в ответе

> Поиск текста не чувствителен к регистру.

Для этого типа мониторинга требуется тело ответа, поэтому методы **HEAD** и **OPTIONS** недоступны — используйте **GET** (по умолчанию) или другие методы, которые возвращают тело.

## Порт TCP

Опрос **TCP порта** хорошо подходит для проверки состояние почти любой службы на сервере, например, **базы данных**, **почтового сервера** или **FTP**.

Популярные службы часто используют стандартные порты, например, **25** для **SMTP**, **50** для **POP3**, **53** для **DNS**.

Все популярные порты и службы доступны для быстрого выбора в выпадающем списке при добавлении сервера в мониторинг, но также можно указать любой свой порт из диапазона от **1** до **65535**.

## Мониторинг DNS

_Доступно в тарифах Pro и Team_

Мониторинг **DNS-записей** позволяет отслеживать изменения в DNS-конфигурации вашего домена. Это полезно для контроля целостности инфраструктуры и своевременного обнаружения несанкционированных изменений.

При любом изменении в DNS-записях выбранных типов вы получите уведомление с детальной информацией о том, какие записи были добавлены, удалены или изменены. Это помогает быстро реагировать на потенциальные проблемы с DNS-конфигурацией или попытки несанкционированного доступа.

## Heartbeat

_Доступно в тарифах Pro и Team_

Heartbeat — это мониторинг для фоновых задач и сервисов, которые **сами отправляют запросы** в Statuser по расписанию (например, cron‑джобы, воркеры, бэкапы).

Если heartbeat не пришёл вовремя или вы явно отправили ошибку, Statuser создаёт инцидент и отправляет уведомления. Эти инциденты учитываются в отчётах и на страницах статуса.

---

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


# Heartbeat мониторинг

Входящие запросы от ваших задач или сервисов

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Heartbeat мониторинг | нет | да | да |

Сравнение тарифов: 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

---

Heartbeat — это мониторинг для задач и фоновых процессов без публичного HTTP/TCP‑эндпоинта. Вместо активных проверок из локаций Statuser вы **сами отправляете сигнал (heartbeat)** по расписанию. Если сигнал не пришёл вовремя, создаётся инцидент.

Heartbeat подходит для cron‑задач, бэкапов, ETL‑процессов, CI/CD‑шагов и любых периодических скриптов.

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

После создания сервера с типом мониторинга **Heartbeat** Statuser выдаёт уникальный `heartbeat_token` и URL.

- задача выполняется и отправляет heartbeat
- если heartbeat не пришёл в ожидаемый интервал — создаётся инцидент
- следующий успешный heartbeat автоматически закрывает инцидент

> Поддерживаются методы **GET**, **POST** и **HEAD**. Успешный запрос возвращает
> **204 No Content**. Endpoint `/fail` используется для явного сообщения об
> ошибке выполнения задачи.

## Пример: cron‑задача

Пример ежедневного бэкапа с использованием Heartbeat:

```bash
#!/bin/bash

set -e

# выполняем задачу
pg_dump mydb > backup.sql

# сообщаем об успехе
curl -fsS -X POST "https://hb.statuser.cloud/<token>"
```

Если задача завершилась с ошибкой:

```bash
curl -fsS -X POST "https://hb.statuser.cloud/<token>/fail"
```

Инциденты не создаются до получения первого heartbeat.
Рекомендуется отправить первый запрос сразу после настройки мониторинга, чтобы Statuser начал отслеживание интервалов.

---

Источник: https://statuser.cloud/docs/heartbeat


# Мониторинг медленных ответов

Отслеживание устойчивого увеличения времени ответа и уведомления о деградации производительности

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

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

Доступно в тарифах Pro и 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

---

Мониторинг медленных ответов позволяет обнаружить деградацию производительности в ситуациях, когда сервис формально остаётся доступным, но начинает стабильно отвечать медленнее обычного. Такой тип уведомлений полезен для выявления проблем до появления ошибок и инцидентов недоступности.

Механизм реагирует не на отдельные всплески задержки, а на **устойчивое превышение заданного порога времени ответа**.

> Мониторинг медленных ответов доступен для HTTP/HTTPS‑проверок, поиска текста и опроса TCP‑портов. Для Ping и DNS этот механизм не применяется.

## Как работает срабатывание

Оценка времени ответа выполняется только после получения результатов **из всех выбранных регионов**. Если данные хотя бы из одной локации отсутствуют, такая проверка в расчёт не принимается.

Время отклика анализируется только в том случае, если сервис находится в состоянии `ONLINE` во всех регионах. Если хотя бы в одном регионе проверка возвращается с ошибкой или недоступностью, счётчики медленного ответа сбрасываются. В этом случае система фиксирует инцидент недоступности, а не деградацию производительности.

Уведомление о медленном ответе отправляется, когда время ответа **превышает порог в 3 последовательных проверках подряд**. Превышение должно наблюдаться **во всех регионах одновременно**, что позволяет отсеять локальные сетевые проблемы и кратковременные всплески.

Восстановление фиксируется после 2 подряд проверок, в которых время ответа возвращается в допустимые значения. Для предотвращения дребезга используется пониженный порог восстановления — **80 % от порога срабатывания**. Например, при пороге 1000 мс восстановление будет зафиксировано при задержке менее 800 мс во всех регионах.

## Уведомления и рекомендации

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

Для более стабильной работы рекомендуется использовать как минимум два региона мониторинга и подбирать порог с учётом SLA сервиса. При интервале проверок в одну минуту уведомление о медленном ответе будет отправлено примерно через три минуты устойчивой деградации.

---

Источник: https://statuser.cloud/docs/slow-response-monitoring


# Мониторинг SSL и домена

Отслеживание даты окончания SSL-сертификата и регистрации домена

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Мониторинг SSL | нет | да | да |
| Мониторинг домена | нет | да | да |

Сравнение тарифов: 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

---

В случае мониторинга по HTTP/HTTPS и мониторинга записей DNS доступен контроль SSL-сертификата и домена.
Это позволяет проверить, что сертификат действителен и не содержит ошибок, а у домена не истек срок регистрации и он не заблокирован.

Проверки SSL и домена выполняются автоматически раз в час.

## Проверка SSL-сертификата

Для проверки сертификата выполняется **запрос** к серверу по протоколу **HTTPS**, который позволяет получить информацию о SSL.

Проверяются параметры:
 - **Статус** - действителен сертификат или нет.
 - **Издатель** - организация, выпустившая сертификат.
 - **Срок действия** - дата начала и окончания действия сертификата.
 - **CN (Common Name)** - название организации, для которой выпущен сертификат.
 - **Действительность цепочки сертификатов** - проверяется список сертификатов, которые привели к доверенному корневому сертификату.
 - **SAN (Subject Alternative Name)** - список дополнительных доменов, для которых действителен сертификат.

Отдельным блоком будут отображены ошибки, если они есть. Например, сертификат истек, не действителен или не соответствует домену.

Для SSL-сертификатов по умолчанию включены оповещения на емейл и в телеграм (и могут дополнительно отправляться в вебхук, если он подключен и подписан на `ssl_alerts`):
 - за **14, 7, 3 и 1 день** до окончания срока действия сертификата.
 - об **окончании срока действия** сертификата.
 - об **успешном обновлении** сертификата.

Оповещения можно настроить в панели управления в разделе **Нотификации**.

## Проверка домена

Для проверки домена используется **WHOIS-запрос**, который позволяет получить необходимую информацию о домене.

> Для доменов поддерживается формат IDN (Internationalized Domain Name). Это означает, что можно добавлять домены на любом языке, например, русском, китайском или арабском, а также использовать эмодзи в названии.

Проверяются параметры:
 - **статус** - активен домен или нет.
 - **дата регистрации** - когда домен был впервые зарегистрирован.
 - **дата окончания регистрации** - когда домен истекает.
 - **регистратор** - организация, у которой зарегистрирован домен.
 - **NS (Name Server)** - список DNS-серверов, которые отвечают за домен.

Для доменов по умолчанию включены оповещения на емейл и в телеграм (и могут дополнительно отправляться в вебхук, если он подключен и подписан на `domain_alerts`):
- за **30, 14, 7, 3 и 1 день** до окончания регистрации домена.
- об **окончании регистрации** домена.
- об **успешном продлении регистрации** домена.

Также, как и для SSL-сертификатов, оповещения для доменов можно настроить в панели управления в разделе **Нотификации**.

---

Источник: https://statuser.cloud/docs/ssl-domain-checks


# Мониторинг реестра РКН

Проверка нахождения домена в реестре блокировок Роскомнадзора

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

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

Доступно в тарифах Pro и 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 может отслеживать нахождение домена в реестре блокировок Роскомнадзора.
Если домен попадёт в реестр или будет исключён из него — вы узнаете об этом из уведомления, не дожидаясь жалоб пользователей.

## Как включить

Проверка включается тумблером **«Мониторинг реестра РКН»** в продвинутых настройках сервера — при добавлении нового или в настройках существующего. Для серверов на подходящих тарифах она включена по умолчанию.

## Как работает проверка

Statuser сверяет домен сервера с актуальной копией реестра блокировок:

 - **Первая проверка выполняется сразу после добавления сервера** — если домен уже в реестре, уведомление придёт в течение минуты.
 - Дальше проверки выполняются автоматически по мере обновления данных реестра — **несколько раз в сутки**.
 - Запись реестра распространяется на домен **вместе с поддоменами**: если в реестре находится `example.com`, то заблокированным будет считаться и `api.example.com`.
 - Поддерживаются **IDN-домены** — кириллические и любые другие национальные доменные имена.

> Проверка выполняется по доменному имени, а не по IP-адресу. Это осознанное решение: на одном IP (например, у CDN или виртуального хостинга) размещаются тысячи сайтов, и проверка по IP давала бы ложные срабатывания из-за «соседей».

## Что вы увидите при блокировке

 - **Карточка «Реестр РКН»** на дашборде сервера с предупреждением о блокировке.
 - **Строка статуса** в информации о домене — с записью реестра, по которой сматчился домен, и ссылкой на официальный сервис проверки.
 - **Иконка предупреждения** в общем списке серверов — как при истёкшем сертификате или домене.

## Уведомления

По умолчанию оповещения включены на емейл, в Телеграм и MAX (и могут дополнительно отправляться в вебхук, если он подключен и подписан на `blocklist_alerts`):

 - о **попадании домена в реестр** блокировок.
 - об **исключении домена из реестра** — когда блокировка снята.

Каждое событие отправляется один раз — повторных уведомлений об одном и том же состоянии не будет. Настроить каналы можно в панели управления в разделе **Нотификации**, тип уведомлений — **«Реестр РКН»**.

## Что важно учитывать

 - Statuser фиксирует **формальное наличие домена в реестре**. Фактические ограничения у конкретных провайдеров могут вводиться с задержкой после появления записи и сниматься не сразу после исключения.
 - Отдельные виды ограничений (например, на уровне ТСПУ) могут не отражаться в публичном реестре — при подозрении на блокировку рекомендуем дополнительно проверить домен на официальном сервисе [blocklist.rkn.gov.ru](https://blocklist.rkn.gov.ru/).
 - Причину включения в реестр Statuser не сообщает — её можно узнать на официальном сервисе по домену.

---

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


# Типы DNS записей

Описание типов DNS-записей доступных для мониторинга

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Мониторинг DNS | нет | да | да |
| История DNS записей | нет | 60 дней | 180 дней |

Сама справка по типам записей полезна на любом тарифе, но мониторинг DNS и история изменений записей доступны с тарифа Pro.

Сравнение тарифов: 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

---

При настройке мониторинга DNS-записей вы можете выбрать один или несколько типов записей для отслеживания. Каждый тип записи имеет своё назначение и формат.

> При мониторинге DNS в Statuser вы можете выбрать один или несколько типов
> записей. Рекомендуется отслеживать критичные для вашей инфраструктуры типы —
> например, A, AAAA для веб-серверов, MX для почты, TXT для верификации
> сервисов.

## A (Address Record)

**A-запись** сопоставляет доменное имя с IPv4-адресом. Это один из самых распространённых типов DNS-записей.

**Пример:**

```
example.com → 192.168.1.1
```

**Применение:**

* Основная запись для связи домена с IP-адресом сервера
* Используется для веб-сайтов, почтовых серверов и других сервисов
* Важна для определения доступности ресурса — изменение IP может привести к сбоям или перенаправлению трафика

## AAAA (IPv6 Address Record)

**AAAA-запись** аналогична A-записи, но указывает на IPv6-адрес вместо IPv4.

**Пример:**

```
example.com → 2001:0db8:85a3:0000:0000:8a2e:0370:7334
```

**Применение:**

* Поддержка современного протокола IPv6
* Обеспечение доступности сервисов через IPv6-сети
* Позволяет пользователям с IPv6-доступом подключаться напрямую без NAT

## CNAME (Canonical Name Record)

**CNAME-запись** создаёт псевдоним (алиас) для другого доменного имени. Она перенаправляет один домен на другой.

**Пример:**

```
www.example.com → example.com
blog.example.com → example.com
```

**Применение:**

* Создание поддоменов, указывающих на основной домен
* Упрощение управления DNS при использовании CDN или балансировщиков
* Часто используется для интеграции сторонних сервисов (например, GitHub Pages, Vercel)

> **Важно**
> CNAME-запись не может сосуществовать с другими записями для того же имени.
> Например, если для `www.example.com` создана CNAME-запись, для этого имени
> нельзя создать A или MX записи.

## NS (Name Server Record)

**NS-запись** указывает, какие DNS-серверы являются авторитетными для домена.

**Пример:**

```
example.com → ns1.nameserver.com
example.com → ns2.nameserver.com
```

**Применение:**

* Делегирование управления DNS-зоной конкретным серверам имён
* Настройка поддоменов с отдельными DNS-серверами
* Критично для корректной работы домена — изменение NS часто сигнализирует о смене хостинг-провайдера или взломе DNS

## MX (Mail Exchange Record)

**MX-запись** определяет почтовые серверы, которые обрабатывают электронную почту для домена, и их приоритет.

**Пример:**

```
example.com → 10 mail1.example.com
example.com → 20 mail2.example.com
```

Число перед именем сервера — это приоритет. Чем меньше число, тем выше приоритет.

**Применение:**

* Настройка маршрутизации электронной почты
* Обеспечение резервирования почтовых серверов
* Изменение MX может повлиять на доставку писем, поэтому мониторинг этих записей особенно важен

## TXT (Text Record)

**TXT-запись** содержит произвольный текст. Используется для различных целей верификации и настройки сервисов.

**Пример:**

```
example.com → "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com → "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
```

**Применение:**

* Верификация владения доменом (Google, Microsoft и др.)
* Настройка SPF для защиты от спама
* Конфигурация DMARC и DKIM для email-аутентификации
* Хранение других метаданных (например, ключей API или параметров интеграций)
* Важно отслеживать, чтобы никто не изменил SPF или DKIM-записи — это может привести к подмене отправителя

## SRV (Service Record)

**SRV-запись** определяет местоположение серверов для определённых сервисов.

**Формат:**

```
_service._proto.name TTL class SRV priority weight port target
```

**Пример:**

```
_sip._tcp.example.com → 10 60 5060 sipserver.example.com
```

**Применение:**

* Настройка VoIP (SIP, XMPP)
* Конфигурация Microsoft Active Directory и других корпоративных сервисов
* Указание серверов для специфичных протоколов
* Важно для распределённых систем — изменение SRV-записей может нарушить маршрутизацию трафика

## PTR (Pointer Record)

**PTR-запись** выполняет обратное DNS-разрешение — преобразует IP-адрес обратно в доменное имя.

**Пример:**

```
1.1.168.192.in-addr.arpa → example.com
```

**Применение:**

* Обратное разрешение DNS для проверки легитимности
* Требуется для некоторых почтовых серверов (проверка отправителя)
* Логирование и аудит сетевой активности
* Несоответствие PTR-записей может вызывать проблемы с доставкой почты и доверием к домену

## SOA (Start of Authority Record)

**SOA-запись** содержит административную информацию о DNS-зоне, включая основной сервер имён, email администратора и параметры обновления зоны.

**Пример:**

```
example.com SOA ns1.example.com. admin.example.com. (
    2024010101 ; Serial
    7200       ; Refresh
    3600       ; Retry
    1209600    ; Expire
    86400      ; Minimum TTL
)
```

**Применение:**

* Определение параметров зоны DNS
* Контроль синхронизации между первичным и вторичными DNS-серверами
* Изменения параметров SOA могут повлиять на скорость обновления DNS-записей

> **Примечание**
> Мониторинг DNS помогает вовремя замечать важные изменения — от смены IP-адреса до
> модификации SPF-записей или делегирования NS. Это повышает безопасность и стабильность
> инфраструктуры.

---

Источник: https://statuser.cloud/docs/dns-record-types


# Ложные срабатывания

Механизм проверки при недоступности сервиса и обработка ложных срабатываний

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Создание инцидентов | да | да | да |
| Количество регионов проверок | 2 региона | 5 регионов | 5 регионов |
| Выбор конкретных регионов | нет | да | да |
| Задержка подтверждения сбоя | нет | нет | да |
| Учащённый мониторинг после сбоя | нет | да | да |

Подтверждение сбоя по нескольким регионам работает на всех тарифах, но количество доступных регионов зависит от тарифа: на Free их два.

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

---

При мониторинге серверов и сервисов могут возникать ложные срабатывания — ситуации, когда система сообщает о проблеме, хотя на самом деле всё работает корректно. Statuser использует различные механизмы для минимизации таких ситуаций в зависимости от типа мониторинга.

## Проверки доступности (HTTP/HTTPS, Ping, TCP)

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

Чтобы минимизировать такие ошибки, Statuser выполняет проверки из нескольких регионов — из **Москвы**, **Санкт-Петербурга**, **Алматы**, **Амстердама** и **Нью-Йорка**. При добавлении сервера вы можете выбрать, из каких регионов выполнять мониторинг.

> Не рекомендуется выполнять проверки только из одного региона — это может
> привести к ложным срабатываниям при кратковременных проблемах в конкретной
> локации. Для надёжности рекомендуется выбрать хотя бы два региона.

Кроме географического распределения, для повышения надёжности используется механизм повторных попыток. Если первая проверка завершилась с ошибкой, Statuser выполнит ещё две повторные попытки с увеличивающимся интервалом:

- После 1-й неудачной попытки — повтор через 700 мс
- После 2-й — ещё одна попытка через 1500 мс

Сервис будет считаться недоступным, только если все 3 попытки в каждом из выбранных регионов завершились неудачно.

#### Пример поведения

```plaintext
Москва →
1.	Первая проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → Через 700 мс →
2.	Вторая проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → Через 1500 мс →
3.	Третья проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → [Недоступен]

Алматы →
...

Амстердам →
...
```

Общее время проверки складывается из времени выполнения трёх попыток и интервалов между ними.

## Мониторинг DNS-записей

При мониторинге DNS-записей важно учитывать, что изменения в DNS могут быть временными или связаны с переносом записей между серверами. Чтобы избежать ложных уведомлений о таких изменениях, Statuser использует систему отложенных уведомлений.

**Как это работает:**

1. При обнаружении изменения в DNS-записях (добавление, удаление или модификация) система не отправляет уведомление сразу
2. Вместо этого запускается таймер ожидания на **15 минут**
3. По истечении этого времени система сравнивает текущее состояние DNS-записей с тем, что было зафиксировано в начале
4. Уведомление отправляется только в том случае, если изменения сохранились

Этот механизм позволяет отфильтровать временные изменения, которые могут возникать:

- При обновлении DNS-записей с коротким TTL
- Во время миграции между DNS-серверами
- При балансировке нагрузки с динамическими записями
- При временных сбоях в DNS-инфраструктуре

> Если за 15-минутный период DNS-записи вернулись к исходному состоянию,
> уведомление не будет отправлено. Это помогает избежать ложных тревог при
> кратковременных флуктуациях DNS.

Благодаря этому подходу вы получаете уведомления только о действительно важных и устойчивых изменениях в DNS-конфигурации вашего домена.

---

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


# Учащённый мониторинг после сбоя

Временное повышение частоты проверок во время инцидента для быстрого обнаружения восстановления

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Учащённый мониторинг после сбоя | нет | да | да |

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

---

Когда сервис падает, Statuser временно повышает частоту проверок — чтобы вы быстрее узнали о восстановлении. После того как сервис восстановится и какое-то время проработает стабильно, монитор возвращается к обычному интервалу. Учащённый мониторинг включается автоматически, настраивать ничего не нужно.

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

Как только сервис признан недоступным (проверка провалилась во всех выбранных регионах — см. [Ложные срабатывания](/docs/false-positives)), монитор переходит в ускоренный режим:

- проверки выполняются каждые **30 секунд**, независимо от вашего обычного интервала;
- благодаря этому восстановление фиксируется быстрее, а инцидент закрывается почти сразу после того, как сервис снова заработал;
- после восстановления ускоренный режим держится ещё около **10 минут** — чтобы поймать повторный сбой, если сервис «моргает»;
- если недоступность длится дольше **часа**, частота возвращается к обычной: на затяжной аварии посекундная детализация уже не нужна.

> Ускоренный режим не меняет ваш обычный интервал проверки — это временная мера
> только на время инцидента и короткого периода после него. Больше всего пользы он
> приносит мониторам с большим интервалом: например, при проверке раз в 5 минут
> восстановление вы бы заметили только через 5 минут, а в ускоренном режиме — за 30
> секунд.

## Как понять, что режим активен

Пока монитор в ускоренном режиме, в строке статуса вместо обычного интервала показывается **«Ускоренная проверка каждые 30 секунд»**. На графике времени ответа точки в этот период идут чаще.

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

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

---

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


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

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

> Индекс всей документации в 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


# User-Agent и IP-адреса для проверок

Как настроить доступ к вашему сервису: User-Agent и список IP-адресов, с которых Statuser выполняет проверки

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

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

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

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

---

Statuser подписывает все исходящие HTTP-запросы к вашим сервисам с помощью постоянного, неизменяемого User-Agent:

```plaintext
Mozilla/5.0 (compatible; Statuser Bot; https://statuser.cloud/)
```

Мы **настоятельно рекомендуем** настраивать правила брандмауэра или прокси на основе этого User-Agent, а не IP-адресов. Такой подход:

- **Стабильнее** — User-Agent не изменяется;
- **Проще в обслуживании** — не требует регулярного обновления IP-списка;
- **Менее подвержен ложным срабатываниям** при изменении инфраструктуры.

Вы можете ограничить доступ к своему сервису только для этого User-Agent — это безопасно и эффективно.

Однако, если по соображениям безопасности вы предпочитаете использовать фильтрацию по IP-адресам — ниже представлен актуальный список.

## IP-адреса Statuser

Для проверок Statuser использует IP-адреса:

**🇷🇺 Москва**

```text
194.87.151.189
109.73.195.20
109.73.202.30
195.133.73.199
109.73.201.59
```

**🇷🇺 Санкт-Петербург**

```text
188.225.25.75
92.255.79.33
82.97.241.159
185.200.241.164
81.200.150.157
```

**🇳🇱 Амстердам**

```text
147.45.174.102
45.139.76.38
212.192.217.180
95.140.159.21
195.133.77.248
```

**🇰🇿 Алматы**

```text
147.45.172.38
45.82.14.253
94.198.220.174
94.198.221.169
188.225.31.15
```

**🇺🇸 Нью-Йорк**

```text
166.1.227.179
166.1.227.192
166.1.227.138
166.1.227.127
166.1.227.55
```

> IP-адреса могут меняться без предварительного уведомления. Рекомендуем
> автоматизировать их обновление с помощью cron-скрипта.

## Машиночитаемые форматы

Если вы хотите обрабатывать IP-адреса в автоматическом виде — они доступны по следующим ссылкам:

- [TXT-версия списка IP-адресов](https://statuser.cloud/meta/ips.txt)
- [JSON-версия списка IP-адресов](https://statuser.cloud/meta/ips.json)

## Получение IP Statuser по DNS

Доменное имя [ip.statuser.cloud](https://www.nslookup.io/domains/ip.statuser.cloud/dns-records/) содержит актуальные A-записи всех IP-адресов агентов Statuser, позволяя автоматически получать список IP через DNS.

Подходит для оборудования вроде MikroTik, Keenetic, Fortinet и OPNsense, которое умеет:

- резолвить доменное имя,
- автоматически обновлять адрес-листы,
- применять firewall-правила без ручного обновления.

## Инструкции по добавлению IP-адресов в файрвол

Мы подготовили краткие инструкции по настройке популярных брандмауэров, чтобы разрешить входящие подключения от агентов мониторинга Statuser.

#### Windows Defender Firewall

1. Откройте **Брандмауэр Защитника Windows в режиме повышенной безопасности** (Windows Defender Firewall with Advanced Security).
2. Нажмите на **Правила для входящих подключений** (Inbound Rules) -> **Создать правило** (New Rule).
3. Выберите **Настраиваемые** (Custom) для типа правила и нажмите **Далее** (Next).
4. На вкладке **Область** (Scope), в разделе **Удаленный IP-адрес** (Remote IP address), выберите **Указанные IP-адреса** (These IP addresses) и нажмите **Добавить** (Add).
5. Введите наши IP-адреса мониторинга и нажмите **ОК**.
6. Завершите мастер создания правила.

[Microsoft Docs - Настройка брандмауэра Защитника Windows](https://learn.microsoft.com/ru-ru/windows/security/operating-system-security/network-security/windows-firewall/configure)

#### Linux iptables

1. Откройте терминал.
2. Выполните следующую команду для каждого IP-адреса:

```
sudo iptables -A INPUT -s [IP_ADDRESS] -j ACCEPT

```

3. Сохраните конфигурацию iptables, чтобы изменения сохранились после перезагрузки.

[Документация проекта Netfilter/iptables](https://netfilter.org/documentation/)

#### Linux UFW (Uncomplicated Firewall)

1. Откройте терминал.
2. Выполните команду:

```
sudo ufw allow from [IP_ADDRESS]
    
```

3. Перезагрузите UFW для применения изменений:

```
sudo ufw reload
    
```

[Ubuntu Community Help - UFW](https://help.ubuntu.com/community/UFW)

#### Cisco ASA Firewall

1. Войдите в Cisco ASDM или CLI.
2. Перейдите в **Configuration** > **Firewall** > **Access Rules**.
3. Добавьте новое правило, разрешающее трафик с наших IP-адресов мониторинга на ваш сервер.
4. Примените и сохраните конфигурацию.

[Cisco ASA Series Firewall CLI Configuration Guides](https://www.cisco.com/c/en/us/support/security/adaptive-security-appliance-asa-software/products-installation-and-configuration-guides-list.html)

---

Источник: https://statuser.cloud/docs/statuser-user-agent-and-ips


# Используемые DNS

Какие DNS серверы используются при проверках сайтов

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

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

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

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

---

Для разрешения доменных имен Statuser использует комбинацию DNS надежных и стабильных провайдеров.

**IPv4:**

```text
92.53.116.104 // Timeweb Cloud
8.8.8.8 // Google
1.1.1.1 // Cloudflare
77.88.8.8 // Yandex
```

**IPv6:**

```text
2a03:6f00:1:2::5c35:7468 // Timeweb Cloud
2001:4860:4860::8888 // Google
2606:4700:4700::1111 // Cloudflare
2a02:6b8::feed:0ff // Yandex
```

---

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


# Создание инцидента

Процесс создания инцидента и таймлайн событий

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Создание инцидентов | да | да | да |
| Хранение инцидентов | 7 дней | 60 дней | 180 дней |
| Таймлайн инцидента | да | да | да |
| Скачивание PDF отчета | нет | да | да |
| Комментарии к инцидентам | нет | нет | да |

Инциденты создаются и хранятся на всех тарифах, различается только срок хранения истории. PDF-отчёт доступен с тарифа Pro.

Сравнение тарифов: 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 инцидент создается автоматически, когда отслеживаемый сервис становится недоступным.

Инцидент позволяет собрать в одном месте всю информацию о проблеме, а также отслеживать ее статус и прогресс решения.

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

> В Statuser все ошибки мониторинга имеют свой код, который позволит быстро понять, что произошло. Все коды ошибок и их описание можно посмотреть в [отдельной статье](/docs/error-codes).

## История инцидента

В истории инцидента можно увидеть все события, которые обработал или выполнил Statuser:

1. **Ошибка мониторинга** - с этого события начинается любой инцидент. Это событие показывает время провалившейся проверки, локацию, откуда проверка выполнялась и причину ошибки.
2. **Начало инцидента** - время создания инцидента.

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

3. **Отправка уведомления** - когда инцидент создан или завершен, Statuser отправляет уведомление на емейл, в Телеграм, MAX и в вебхук (если каналы включены в настройках) со статусом инцидента. Для каждой отправки уведомления создается отдельное событие в истории, которое позволяет увидеть, когда и куда было отправлено уведомление и статус доставки этого уведомления.
4. **Изменение ошибки проверки** - если во время инцидента произошла ошибка проверки, которая отличается от предыдущей ошибки, то это также отразится в истории. Это особенно полезно, когда первоначальная проблема решена, но сервис продолжает выдавать ошибки по другим причинам.
5. **Успешная проверка** - первая успешная проверка после недоступности сервиса. Это событие показывает, что сервис восстановлен и проверки из каждой локации проходят успешно.
6. **Завершение инцидента** - когда сервис восстановлен и проверки проходят успешно, инцидент завершается.
7. **Комментарий к инциденту** - к каждому инциденту можно оставить комментарий или написать постмортем. Комментарии позволяют зафиксировать все действия, которые были сделаны для решения проблемы и сохранить полученный опыт. Подробнее о работе комментариев в статье [Комментарии к инцидентам](/docs/incident-comments).

## PDF-отчёт по инциденту

_Доступно в тарифах Pro и Team_

В Statuser можно скачать PDF-отчёт по каждому инциденту. Это удобно, если нужно отправить итоговый отчёт клиенту, провайдеру или сохранить материалы для внутреннего постмортема.

Чтобы скачать отчёт:

1. Откройте нужный инцидент в разделе [Инциденты](/my/incidents).
2. Нажмите кнопку **Отчёт**.
3. Выберите, какие разделы включить в PDF.
4. Подтвердите скачивание.

В отчёт всегда включается основная информация об инциденте. Дополнительно можно выбрать остальные доступные разделы.

## Удаление инцидента

Инцидент можно удалить — например, если проверка сработала ложно и портит статистику доступности.

Удалить инцидент можно двумя способами:

- откройте инцидент в разделе [Инциденты](/my/incidents) и нажмите кнопку **Удалить**;
- либо нажмите **⋯** в строке инцидента в списке и выберите **Удалить инцидент**.

Вместе с инцидентом удаляются сетевая диагностика, скриншот, комментарии, AI-саммари и история отправленных уведомлений. Восстановить удалённый инцидент нельзя.

> Аптайм считается по инцидентам, поэтому после удаления процент доступности сервера вырастет — и на статус-странице, и в отчётах, которые будут сформированы после удаления. Уже выпущенные отчёты сохранят прежние цифры.

Активный инцидент удалить нельзя: сервис ещё недоступен, и следующая проверка создала бы инцидент заново. Дождитесь восстановления сервиса — после этого инцидент можно удалить.

## Автоматическая приостановка серверов

Если инцидент остаётся активным более 30 дней, Statuser автоматически приостанавливает мониторинг сервера.

Одновременно с этим инцидент автоматически закрывается со статусом таймаута.

Это помогает:
- исключить забытые или выведенные из эксплуатации серверы,
- сохранить чистоту интерфейса и точность отчётов,
- снизить ненужную нагрузку на систему.

Проверки приостанавливаются, но сервер остаётся доступным — мониторинг можно включить вручную в любой момент.

---

Источник: https://statuser.cloud/docs/incidents


# Диагностика инцидента

Инструменты диагностики проблемы при получении ошибки

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

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

Доступно в тарифах Pro и 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 осуществляет сбор ключевых диагностических данных, позволяя локализовать проблему и определить, связана ли она с сетевой инфраструктурой, отказами серверного оборудования, некорректными DNS-конфигурациями или ошибками в реализации приложения. В этой статье описано, как анализировать эти данные и применять их для выявления причин сбоев в работе сервера.

## HTTP-ответ, тело и заголовки

**_Доступно только при HTTP/HTTPS проверках._**

Анализ HTTP-ответов позволяет определить тип отказа и возможные причины:

- **Коды 4xx** свидетельствуют о проблемах на стороне клиента (например, некорректные запросы, ошибки аутентификации, блокировки доступа);
- **Коды 5xx** указывают на сбои серверного программного обеспечения (перегрузка, ошибки конфигурации, сбои в обработке запросов);
- **Тело ответа** может включать специфические диагностические сообщения от серверных компонентов, например, об ошибках в работе базы данных или превышении лимита запросов;
- **Заголовки ответа** содержат критически важную метаинформацию: идентификацию серверного ПО, параметры кэширования, политики безопасности (CSP, CORS) и сжатия трафика.

> Полный список HTTP кодов ошибок, которые обрабатывает Statuser, описан в
> [отдельной статье](/docs/error-codes).

## Скриншот состояния сайта

**_Доступно только при HTTP/HTTPS проверках._**

Фиксация визуального состояния страницы на момент сбоя помогает верифицировать:

- некорректный рендеринг контента;
- загрузку частичных элементов или ресурсов (например, ошибки при получении CSS или JavaScript);
- сообщения об ошибках, отображаемые фронтенд-приложением.

## Тайминги

**_Доступно только при HTTP/HTTPS проверках._**

Анализ временных характеристик сетевого запроса помогает выявить, на каком этапе соединение испытывает задержки. Разберём основные параметры:

**Фактический URL** _(effective_url)_ — итоговый URL после всех перенаправлений;

**Число перенаправлений** _(redirect_count)_ — количество выполненных редиректов;

**Время разрешения имени** _(name_lookup_time)_ — время, затраченное на разрешение доменного имени в IP-адрес;

**Время установления соединения** _(connect_time)_ — время установления TCP-соединения;

**Время установления соединения с приложением** _(app_connect_time)_ — время, затраченное на установку защищённого соединения (TLS handshake);

**Время до начала передачи** _(pre_transfer_time)_ — время от начала запроса до момента готовности к передаче данных;

**Время начала передачи** _(start_transfer_time)_ — время от начала запроса до получения первого байта ответа;

**Суммарное время перенаправления** _(redirect_time)_ — общее время, потраченное на редиректы;

**Полное время запроса** _(total_time)_ — общее время выполнения запроса;

**Код HTTP-ответа** _(response_code)_ — HTTP-код ответа сервера.

Эти параметры помогают локализовать источник задержек: например, длительное время разрешения имени может указывать на проблемы с DNS, а высокая время начала передачи — на перегрузку серверной инфраструктуры.

## Зарезолвленные IP-адреса

Анализ IP-адресов, возвращаемых DNS-серверами, позволяет выявить:

- расхождения в конфигурации DNS-записей (например, разное разрешение IP в разных географических регионах);
- случаи попадания IP-адреса в чёрные списки или ошибочную маршрутизацию;
- проблемы с кешированием устаревших DNS-записей.

## Трассировка маршрута (Traceroute)

Используется для диагностики маршрутизации пакетов, позволяет выявить:

- сегменты сети с высокими задержками;
- сбои в промежуточных узлах, приводящие к потере пакетов;
- возможные блокировки трафика на границах автономных систем (AS).

## Гибридный анализ маршрутизации (MTR)

MTR выполняет множественные измерения и фиксирует динамические изменения в маршрутах сети:

- процент потерь пакетов на каждом узле;
- вариативность задержек в реальном времени;
- изменение маршрутов в зависимости от нагрузки на сеть.

## Валидация TLS-сертификатов (OpenSSL)

Диагностика HTTPS-соединений с использованием OpenSSL позволяет определить:

- истечение срока действия сертификата;
- корректность цепочки доверия и проблемы с корневыми центрами сертификации;
- устаревшие или небезопасные криптографические протоколы (например, использование SSL 3.0 или слабых шифров AES128).

## Диагностика сетевой доступности (Ping)

**_Только при проверках Ping._**

Используется для оценки доступности хоста и стабильности соединения:

- отсутствие ответа может свидетельствовать о блокировке ICMP-пакетов или полной недоступности узла;
- высокий уровень потерь пакетов указывает на проблемы с маршрутизацией;
- увеличение задержек сигнализирует о перегрузке сети.

## Анализ портов (Netcat)

Позволяет тестировать доступность конкретных сервисов на сервере:

- закрытые порты могут свидетельствовать о сбоях серверных служб или настройках брандмауэра;
- успешное соединение, но отсутствие ответа указывает на зависание или некорректную работу сервиса.

## ИИ-анализ инцидента

Statuser AI автоматически анализирует данные диагностики — заголовки и тело ответа, трассировку, MTR, ping, nmap и OpenSSL.
На их основе формируется короткое и понятное резюме:
- что произошло, и как проявилась проблема;
- где может находиться причина (сеть, DNS, SSL, приложение);
- на что обратить внимание в первую очередь.

ИИ-анализ не заменяет подробные данные диагностики, а помогает быстрее сориентироваться и сузить круг возможных причин.

---

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


# Комментарии к инциденту

Добавление комментариев к инциденту и обсуждение проблемы

> Индекс всей документации в 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

---

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

Особенно полезно оставлять постмортемы после завершения инцидента.

> Постмортем — это документ, который содержит информацию о причинах инцидента, действиях,
> которые были предприняты для его устранения, и рекомендации по предотвращению подобных ситуаций в будущем.

Пример простого постмортема:

> **Описание инцидента**
> 5 января 2025 года с 10:00 до 10:45 (UTC) наш сервис испытывал недоступность для части пользователей. Проблема была вызвана превышением времени ожидания (таймаута) на уровне приложения, что привело к сбоям в обработке запросов. Основной причиной послужила высокая нагрузка на один из внутренних микросервисов, ответственного за обработку данных, вызвавшая цепочку задержек в системе.
> **Действия по устранению**
> После обнаружения проблемы мы оперативно перенаправили часть трафика на резервный сервер и увеличили таймауты на уровне балансировщика нагрузки, что позволило временно стабилизировать работу. Затем была проведена диагностика узкого места, в результате которой выявлен неэффективный запрос к базе данных. В течение часа запрос был оптимизирован, и нагрузка на систему нормализовалась.
> **План предотвращения**
> Для предотвращения подобных инцидентов мы увеличим частоту тестирования производительности, добавим мониторинг длительности критических запросов и внедрим систему автоматического масштабирования проблемных микросервисов. Также мы сократим значение таймаута на начальном уровне системы, чтобы быстрее определять подобные проблемы, не вызывая цепных сбоев.

## Вложения к комментариям

К комментариям и постмортемам можно прикреплять файлы.

- Поддерживаемые форматы: `png`, `jpg`, `jpeg`, `webp`, `pdf`, `txt`, `log`, `json`, `csv`, `zip`, `md`, `yml`, `yaml`, `xml`, `gz`, `tgz`
- Максимум: до `5` файлов к одному комментарию
- Ограничение размера: до `5 Мбайт` на каждый файл

Вложения полезны, когда нужно сохранить контекст инцидента вместе с комментарием:

- скриншоты ошибок или графиков с резким ростом задержки;
- фрагменты логов (`log`, `txt`) с точным временем и текстом ошибки;
- экспортированные данные для анализа (`csv`, `json`);
- черновик или итоговый постмортем в `md`/`pdf`;
- архив с дополнительными артефактами диагностики (`zip`, `gz`, `tgz`).

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

---

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


# Коды ошибок

Справочник кодов ошибок и их описание

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

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

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

Справочник кодов не зависит от тарифа, но часть кодов относится к проверкам, доступным не на всех тарифах, — например, ошибки SSL, домена и DNS.

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

---

В Statuser обрабатывается **больше 100 уникальных ошибок**, каждая из которых имеет свой код. Это позволяет быстро понять, что произошло и какие действия нужно предпринять для решения проблемы.

Для удобства все ошибки сгруппированы по типам и имеют краткое описание.

#### Ошибки сети

Ошибки, связанные с проблемами подключения или прерываниями в сетевом соединении.

| Ошибка                     | Подробное описание                                             |
|----------------------------|-----------------------------------------------------------------|
| Подключение отклонено      | Сервер отклонил запрос на подключение. |
| Соединение было сброшено   | Соединение с сервером было сброшено на этапе обмена данными.   |
| Сеть недоступна            | Невозможно достичь указанной сети.     |
| Нарушено соединение        | Соединение было прервано на стороне клиента или сервера.       |
| Доступ запрещён            | Запрос на соединение был отклонён из-за отсутствия прав доступа. |
| Хост недоступен            | Указанный хост недоступен для подключения. |
| Сокет был закрыт           | Сокет был закрыт перед завершением операции обмена данными.    |
| Превышено время ожидания подключения | Время ожидания ответа от сервера истекло. |

#### 4xx ошибки HTTP

Ошибки, возникающие из-за неверных запросов, например, из-за неправильного формата данных или отсутствия доступа.

| Ошибка                          | Подробное описание                                                                   |
|---------------------------------|-------------------------------------------------------------------------------------|
| 400 Bad Request                 | Неверный запрос, сервер не может понять или обработать запрос из-за синтаксической ошибки. |
| 401 Unauthorized                | Неавторизованный доступ, требуется аутентификация для выполнения запроса.            |
| 402 Payment Required            | Требуется оплата для продолжения запроса.                                            |
| 403 Forbidden                   | Доступ к ресурсу запрещён.                                                          |
| 404 Not Found                   | Ресурс не найден на сервере.                                                        |
| 405 Method Not Allowed          | Метод HTTP не разрешён для данного ресурса.                                         |
| 406 Not Acceptable              | Формат ответа, указанный в запросе, не поддерживается сервером.                     |
| 407 Proxy Authentication Required | Требуется аутентификация через прокси-сервер для выполнения запроса.                |
| 408 Request Timeout             | Превышено время ожидания запроса от клиента.                                         |
| 409 Conflict                    | Конфликт с текущим состоянием ресурса, запрос не может быть выполнен.                |
| 410 Gone                        | Ресурс был удалён и больше не доступен.                                              |
| 411 Length Required             | Не указан размер содержимого запроса.                                               |
| 412 Precondition Failed         | Не выполнено одно из условий для выполнения запроса.                                |
| 413 Payload Too Large           | Тело запроса слишком велико для обработки сервером.                                 |
| 414 URI Too Long                | URI запроса слишком длинный для обработки сервером.                                 |
| 415 Unsupported Media Type      | Тип медиа в запросе не поддерживается сервером.                                      |
| 416 Range Not Satisfiable       | Запрашиваемый диапазон данных не может быть удовлетворён сервером.                  |
| 417 Expectation Failed          | Ожидания, указанные в запросе, не могут быть выполнены сервером.                    |
| 418 I'm a teapot                | Это шутка, сервер возвращает ответ "я чайник".                                      |
| 421 Misdirected Request         | Запрос направлен не на тот сервер, который может его обработать.                   |
| 422 Unprocessable Entity        | Запрос не может быть обработан из-за синтаксической ошибки в содержимом.            |
| 423 Locked                      | Ресурс заблокирован и не может быть изменён.                                         |
| 424 Failed Dependency           | Запрос не может быть выполнен из-за сбоя в зависимых запросах.                      |
| 425 Too Early                   | Запрос поступил слишком рано, сервер ещё не готов к его обработке.                  |
| 426 Upgrade Required            | Требуется обновление протокола для выполнения запроса.                              |
| 428 Precondition Required       | Требуется выполнение предварительных условий для выполнения запроса.               |
| 429 Too Many Requests           | Слишком много запросов было отправлено за короткий промежуток времени.             |
| 431 Header Fields Too Large     | Заголовки запроса слишком большие для обработки сервером.                           |
| 451 Unavailable For Legal Reasons | Доступ к ресурсу ограничен по юридическим причинам.                                 |

#### 5xx ошибки HTTP

Ошибки, возникающие на сервере, находящемся под мониторингом, когда он не может обработать запрос из-за внутренних проблем.

| Ошибка                          | Подробное описание                                                                 |
|---------------------------------|-----------------------------------------------------------------------------------|
| 500 Internal Server Error       | Внутренняя ошибка сервера, запрос не может быть выполнен из-за проблем на сервере.|
| 501 Not Implemented             | Сервер не поддерживает функциональность, необходимую для выполнения запроса.     |
| 502 Bad Gateway                 | Ошибка шлюза, сервер получил некорректный ответ от вышестоящего сервера.          |
| 503 Service Unavailable         | Сервис временно недоступен, возможно, из-за перегрузки или технического обслуживания.|
| 504 Gateway Timeout             | Превышено время ожидания ответа от вышестоящего сервера.                          |
| 505 HTTP Version Not Supported  | Запрашиваемая версия HTTP не поддерживается сервером.                             |
| 506 Variant Also Negotiates     | Ошибка при попытке согласования варианта контента на сервере.                    |
| 507 Insufficient Storage        | На сервере недостаточно места для выполнения запроса.                             |
| 508 Loop Detected               | Обнаружен бесконечный цикл при обработке запроса.                                 |
| 510 Not Extended                | Запрос требует дополнительных расширений, которые не поддерживаются сервером.   |
| 511 Network Authentication Required | Требуется аутентификация для доступа к сети.                                      |

#### Ошибки Nginx

Ошибки, связанные с проблемами конфигурации и обработки запросов в веб-сервере Nginx.

| Ошибка                     | Подробное описание                                                    |
|----------------------------|------------------------------------------------------------------------|
| Нет ответа от сервера         | Сервер не предоставил ответ и закрыл соединение, возможно, из-за внутренней ошибки.|
| Слишком большой заголовок | Размер заголовка запроса превышает допустимые ограничения, установленные на сервере.|
| Неверный клиентский сертификат    | Клиентский сертификат недействителен или не соответствует требованиям сервера.    |
| Требуется клиентский сертификат  | Для установления соединения требуется предоставить корректный клиентский сертификат.|
| HTTP-запрос на HTTPS-порт | Запрос с использованием HTTP протокола отправлен на порт, ожидающий HTTPS соединения. |
| Клиент закрыл соединение          | Клиент завершил соединение до получения полного ответа от сервера.                |

#### Ошибки Cloudflare

Ошибки, связанные с проблемами конфигурации и обработки запросов при использовании Cloudflare.

| Ошибка                     | Подробное описание                                                    |
|----------------------------|------------------------------------------------------------------------|
| Неизвестный ответ             | Сервер вернул пустой или неизвестный ответ.         |
| Сервер недоступен             | Сервер отказал в соединении.                        |
| Таймаут соединения            | Превышено время ожидания соединения с сервером.     |
| Неверные DNS-записи           | Сервер недоступен, возможно из-за неверных DNS-записей. |
| Таймаут HTTP-ответа           | Превышено время ожидания HTTP-ответа от сервера.    |
| Ошибка SSL/TLS рукопожатия    | Произошла ошибка при установлении SSL/TLS соединения.|
| Неверный SSL-сертификат       | Установлен некорректный SSL-сертификат на сервере.  |

#### Ошибки AWS

Ошибки, происходящие в облачной инфраструктуре AWS, связанные с некорректной конфигурацией или аутентификацией.

| Ошибка                         | Подробное описание                                                                                 |
|--------------------------------|-----------------------------------------------------------------------------------------------------|
| Клиент закрыл соединение       | Соединение было завершено клиентом до истечения установленного времени ожидания.                   |
| Слишком много IP-адресов       | Количество IP-адресов в заголовке X-Forwarded-For превышает допустимый лимит (30).                 |
| Несовместимость протоколов     | Версии протоколов, используемые клиентом и сервером, несовместимы для установления соединения.     |
| Ошибка аутентификации          | Запрос не был аутентифицирован из-за ошибок взаимодействия с провайдером идентификации.            |

#### Ошибки при поиске текста

Ошибки, возникающие при проверке наличия/отсутствия текста в HTTP‑ответе.

| Ошибка | Подробное описание |
|---|---|
| Текст не найден | Указанный текст не найден в ответе (в режиме «Успех, если текст есть»). |
| Текст найден | Текст найден в ответе, но ожидалось отсутствие (в режиме «Успех, если текста нет»). |

#### Ошибки DNS

Ошибки, связанные с разрешением доменных имен и поиском серверов по их именам.

| Ошибка                     | Подробное описание                                                    |
|----------------------------|------------------------------------------------------------------------|
| Хост не найден             | Указанный хост не найден в DNS. Это может быть связано с некорректным именем хоста или его отсутствием в системе имен. |
| Временная ошибка DNS       | Произошла временная ошибка при обращении к DNS. |
| Указанный адрес недоступен | Указанный IP-адрес недоступен или не может быть использован для подключения. |

### Ошибки SSL

Ошибки, возникающие при установлении защищённого SSL-соединения.

| Ошибка                                   | Подробное описание                                                                              |
|------------------------------------------|--------------------------------------------------------------------------------------------------|
| Самоподписанный сертификат               | Установлен самоподписанный сертификат, который не может быть проверен доверенными центрами сертификации. |
| Самоподписанный сертификат в цепочке     | В цепочке сертификатов найден самоподписанный сертификат, что нарушает требования безопасности.  |
| Неверное имя в TLS сертификате           | Имя хоста не соответствует имени, указанному в поле **Subject Alternative Name** TLS-сертификата.   |
| Невозможно проверить подпись сертификата | Подпись сертификата не может быть проверена, вероятно, из-за отсутствия доверия к его центру сертификации. |
| Срок действия сертификата истёк          | Срок действия TLS-сертификата истёк, требуется его обновление.                                  |
| Сертификат ещё недействителен            | Сертификат еще не начал действовать. |
| Размер параметров DH слишком мал         | Размер параметров Диффи-Хеллмана (DH) слишком мал для обеспечения безопасного соединения.        |
| TLS повторное согласование отключено     | Попытка выполнения повторного согласования в TLS-соединении была отклонена, так как эта функция отключена. |

#### Ошибки cURL

Для выполнения запросов из Statuser используется библиотека cURL. Для этой библиотеки может возникнуть ряд ошибок, которые могут быть связаны с некорректными параметрами запроса, сетевыми проблемами или ошибками на сервере.

| Ошибка                          | Подробное описание                                                                   |
|---------------------------------|-------------------------------------------------------------------------------------|
| Неподдерживаемый протокол       | Указанный протокол не поддерживается текущей версией cURL.                           |
| Ошибка инициализации            | Не удалось выполнить начальную настройку cURL для запроса.                           |
| Неверный URL                    | Синтаксис URL указан неверно, проверьте формат.                                      |
| Функция отключена               | Требуемая функция или опция отключена в данной сборке cURL.                         |
| Прокси не найден                | Указанный прокси-сервер не может быть разрешён.                                     |
| Хост не найден                  | Указанный хост не может быть разрешён (ошибка DNS).                                 |
| Хост недоступен                 | Не удалось установить соединение с указанным хостом.                                |
| Непонятный ответ сервера        | Сервер отправил данные, которые cURL не смог разобрать.                             |
| Доступ к FTP запрещён           | Сервер FTP отклонил вход или доступ к ресурсу.                                      |
| Ошибка FTP-подключения          | Ошибка при ожидании активного подключения FTP.                                      |
| Неверный ответ PASS             | Сервер FTP отправил непонятный ответ на команду PASS.                               |
| Таймаут FTP                     | Превышено время ожидания активного подключения FTP.                                 |
| Неверный ответ PASV             | Сервер FTP отправил непонятный ответ на команду PASV.                               |
| Неверный формат 227             | Неправильный формат строки 227, отправленной сервером FTP.                          |
| Неверный IP-адрес               | Не удалось разрешить IP-адрес хоста из строки 227.                                  |
| Ошибка HTTP/2                   | Произошла ошибка в слое HTTP/2.                                                     |
| Ошибка режима FTP               | Не удалось переключиться на бинарный режим передачи данных.                         |
| Частичная загрузка              | Была передана только часть файла.                                                   |
| Ошибка загрузки FTP             | Не удалось загрузить файл с FTP-сервера.                                            |
| Ошибка команды QUOTE            | Ошибка при выполнении пользовательской команды QUOTE.                               |
| HTTP-ошибка                     | Сервер вернул ошибку HTTP (код 400 или выше).                                       |
| Ошибка записи                   | Произошла ошибка при записи данных.                                                 |
| Ошибка отправки FTP             | Не удалось отправить файл на FTP-сервер.                                            |
| Ошибка чтения                   | Произошла ошибка при чтении данных.                                                 |
| Недостаточно памяти             | Не хватает памяти для выполнения операции.                                          |
| Таймаут операции                | Превышено время ожидания выполнения операции.                                       |
| Ошибка команды PORT             | Ошибка при выполнении команды PORT в FTP.                                           |
| Ошибка команды REST             | Ошибка при выполнении команды REST в FTP.                                           |
| Ошибка RANGE                    | Ошибка при обработке диапазона данных.                                              |
| Ошибка POST                     | Ошибка при генерации или отправке POST-запроса.                                     |
| Ошибка SSL                      | Не удалось установить SSL-соединение.                                               |
| Ошибка возобновления            | Не удалось возобновить загрузку файла.                                              |
| Файл не читается               | Указанный файл не может быть прочитан.                                              |
| Ошибка LDAP-привязки           | Ошибка при попытке привязки к серверу LDAP.                                         |
| Ошибка LDAP-поиска             | Ошибка при выполнении поиска в LDAP.                                                |
| Функция не найдена              | Требуемая функция LDAP не найдена.                                                 |
| Операция прервана               | Операция была прервана callback-функцией.                                           |
| Неверный аргумент               | Функция вызвана с некорректным параметром.                                          |
| Ошибка интерфейса               | Ошибка при использовании сетевого интерфейса.                                       |
| Слишком много редиректов        | Превышено допустимое количество редиректов.                                         |
| Неизвестная опция               | Использована неизвестная или неподдерживаемая опция.                                |
| Ошибка telnet                   | Неверный синтаксис в опции telnet.                                                  |
| Ошибка сертификата              | Ошибка при проверке SSL-сертификата сервера.                                        |
| Нет ответа                      | Сервер не отправил никаких данных.                                                  |
| SSL-движок не найден            | Указанный SSL-движок не найден.                                                     |
| Ошибка SSL-движка               | Не удалось установить SSL-движок по умолчанию.                                      |
| Ошибка отправки                 | Произошла ошибка при отправке данных.                                               |
| Ошибка получения                | Произошла ошибка при получении данных.                                              |
| Проблема с сертификатом         | Проблема с локальным SSL-сертификатом.                                              |
| Ошибка шифра                    | Не удалось использовать указанный шифр.                                             |
| Ошибка CA                       | Ошибка при проверке CA-сертификата.                                                 |
| Неверное кодирование            | Неверное кодирование содержимого ответа.                                            |
| Неверный URL LDAP               | Указанный URL для LDAP имеет неверный формат.                                       |
| Файл слишком большой            | Размер файла превышает допустимый лимит.                                            |
| Ошибка SSL                      | Общая ошибка при использовании SSL.                                                 |
| Ошибка перемотки                | Ошибка при перемотке данных для повторной отправки.                                 |
| Ошибка инициализации SSL        | Не удалось инициализировать SSL-движок.                                             |
| Ошибка входа                    | Ошибка при попытке входа на сервер.                                                 |
| Файл не найден (TFTP)           | Указанный файл не найден на TFTP-сервере.                                           |
| Ошибка прав (TFTP)              | Недостаточно прав для доступа к файлу на TFTP-сервере.                              |
| Место закончилось               | Недостаточно места на TFTP-сервере для выполнения операции.                         |
| Недопустимая операция           | Попытка выполнить недопустимую операцию на TFTP-сервере.                            |
| Неизвестный ID                  | Неизвестный идентификатор передачи TFTP.                                            |
| Файл существует                 | Указанный файл уже существует на TFTP-сервере.                                      |
| Пользователь не найден          | Указанный пользователь не существует на TFTP-сервере.                               |
| Ошибка преобразования           | Ошибка при преобразовании символов.                                                 |
| Требуется преобразование        | Требуется преобразование символов, но оно не было выполнено.                        |
| Ошибка CA-файла                 | Ошибка при чтении CA-сертификата.                                                   |
| Файл не найден                  | Удалённый файл не найден.                                                           |
| Ошибка SSH                      | Произошла ошибка в SSH-сессии.                                                      |
| Ошибка завершения SSL           | Ошибка при завершении SSL-соединения.                                               |
| Повторить запрос                | Запрос должен быть повторён.                                                        |
| Ошибка CRL-файла                | Ошибка при чтении CRL-файла.                                                        |
| Ошибка издателя                 | Ошибка при проверке издателя сертификата.                                           |
| Ошибка PRET                     | Ошибка при выполнении команды PRET в FTP.                                           |
| Ошибка CSeq                     | Неправильная последовательность CSeq в RTSP.                                        |
| Ошибка сессии RTSP              | Ошибка в идентификаторе сессии RTSP.                                                |
| Ошибка списка файлов            | Ошибка при разборе списка файлов FTP.                                               |
| Ошибка chunk                    | Ошибка в callback-функции chunk.                                                    |
| Нет соединения                  | Нет доступного соединения для выполнения запроса.                                   |
| Неверный ключ                   | Ошибка при проверке публичного ключа.                                               |
| Неверный статус                 | Неверный статус SSL-сертификата.                                                    |
| Ошибка потока HTTP/2            | Ошибка в потоке HTTP/2.                                                             |

#### Общие ошибки

Иногда при проверках могут возникать ошибки, которые не описаны в Statuser.
Например, такое может произойти, если приложение отдает какой-то собственный код ошибки, который не описан в официальных стандартах.

В этом случае будет выведен один из общих кодов.

| Ошибка                  | Подробное описание                                                    |
|-------------------------|-----------------------------------------------------------------------|
| Неизвестная ошибка Ping | Произошла ошибка при выполнении Ping-запроса, причина не установлена. |
| Неизвестная ошибка TCP  | Возникла ошибка при установлении TCP-соединения, причина неизвестна.  |
| Неизвестная ошибка HTTP | Произошла ошибка при выполнении HTTP-запроса, причина не определена.  |
| Код ответа не входит в список успешных | Сервер вернул HTTP-код, который не входит в список ожидаемых успешных кодов, заданных в настройках сервера. |
| Неизвестная ошибка      | Произошла неизвестная ошибка.                                         |

#### Ошибки Heartbeat

Ошибки, связанные с мониторингом Heartbeat (входящие запросы от ваших задач/сервисов).

| Код ошибки          | Подробное описание                                                       |
| ------------------- | ------------------------------------------------------------------------ |
| `heartbeat_timeout` | Heartbeat не пришёл в ожидаемый интервал (с учётом допустимой задержки). |
| `heartbeat_failure` | Задача явно сообщила об ошибке через endpoint `/fail`.                   |

---

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


# Установка Netcat

Инструкция по установке Netcat на Windows, Linux и MacOS

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

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

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

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

---

Netcat (nc) — это простая, но мощная утилита, которая позволяет проверять сетевые соединения, сканировать порты и передавать данные через TCP/UDP.

### Как установить netcat (nc) на Linux

#### Ubuntu / Debian
Чтобы установить netcat, выполните команду:
```sh
sudo apt update && sudo apt install netcat
```

#### CentOS / RHEL / Fedora
Для этих дистрибутивов netcat доступен в пакете `nmap-ncat`:
```sh
sudo yum install nmap-ncat
```

#### Arch / Manjaro
В этих системах netcat можно установить с помощью pacman:
```sh
sudo pacman -S netcat
```

### Как установить netcat (nc) на  macOS
На macOS утилита `nc` уже установлена по умолчанию. Если необходимо переустановить:
```sh
brew install netcat
```

### Как установить netcat (nc) на Windows
На Windows netcat по умолчанию отсутствует. Вместо него можно использовать `ncat` (аналог от Nmap):

1. Загрузите Nmap с официального сайта: [https://nmap.org/download.html](https://nmap.org/download.html)
2. Установите Nmap, включая `Ncat`
3. Используйте команду `ncat` вместо `nc`:
   ```sh
   ncat -zv example.com 443
   ```

### Как проверить установку
После установки выполните команду:
```sh
nc -h
```
Если `nc` установлен, появится справка с доступными параметрами.

---

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


# Каналы уведомлений

Доступные виды нотификаций и их настройка

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Уведомления на емейл | да | да | да |
| Уведомления в Телеграм | да | да | да |
| Уведомления в MAX | да | да | да |
| Уведомления по вебхукам | нет | нет | да |

Емейл, Телеграм и MAX доступны на всех тарифах, вебхуки — на тарифе Team. На всех тарифах действует лимит 30 емейл-уведомлений в сутки; у Телеграма и MAX ограничений нет.

Сравнение тарифов: 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 доступны несколько видов уведомлений, которые можно настроить для вашего проекта. Каждый тип уведомлений настраивается отдельно в панели управления в разделе [Настройки нотификаций](https://statuser.cloud/my/account/notifications).

Поддерживается отправка уведомлений на емейл, в Телеграм, MAX и через вебхуки. Информация об особенностях работы и настройки каждого канала доступна в отдельных статьях:
 - [Уведомления в Телеграм](https://statuser.cloud/docs/telegram-notification)
 - [Уведомления в MAX](https://statuser.cloud/docs/max-notification)
 - [Уведомления на емейл](https://statuser.cloud/docs/email-notification)
 - [Уведомления в вебхук](https://statuser.cloud/docs/webhook-notification)

Емейл, Телеграм и MAX работают на всех тарифах. Вебхуки — только на тарифе Team.

> В будущем планируется добавить новые каналы уведомлений, например SMS и звонки с сервисного номера.

---

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


# Уведомления в Телеграм

Доступные настройки и особенности работы

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

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

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

| Функция | 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

---

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

Для подключения уведомлений необходимо перейти из панели управления по ссылке или отсканировать QR-код в разделе [Настройки нотификаций](https://statuser.cloud/my/account/notifications).

Можно подключить несколько чатов к одному аккаунту Statuser, поддерживаются уведомления как в личные, так и в групповые чаты.

> **Важно**
> У Statuser только один официальный бот [@statuser_notify_bot](https://t.me/statuser_notify_bot), который отправляет уведомления. Не доверяйте другим ботам, которые могут пытаться выдать себя за официального.

### Отправка сообщений в топики

В группах Телеграм с включенными топиками можно настроить отправку уведомлений Statuser в определенную тему. Это позволяет структурировать уведомления и отделить их от основного обсуждения.

Для выбора топика для уведомлений:

1. Перейдите в раздел **Настройки аккаунта** → **Нотификации**
2. Найдите привязанную Телеграм группу
3. Нажмите на текущий топик (по умолчанию **General**)
4. Выберите нужный топик из списка

> **Важно**
> Чтобы тема стала видимой для бота, в ней должно появиться новое сообщение
> после его добавления в группу.

Смена топика происходит мгновенно — новые уведомления сразу будут приходить в выбранную тему.

---

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


# Уведомления в MAX

Подключение, настройка и особенности работы канала

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Уведомления в MAX | да | да | да |

Сравнение тарифов: 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

---

MAX можно использовать как основной канал уведомлений. Канал подходит для быстрых оповещений о смене статуса сервисов и подключается прямо из панели управления.

Для подключения уведомлений откройте раздел [Настройки нотификаций](https://statuser.cloud/my/account/notifications), затем выберите привязку MAX-аккаунта через ссылку или QR-код.

Можно подключить несколько получателей к одному аккаунту Statuser: поддерживаются уведомления как в личные чаты, так и в группы.

> **Важно**
> У Statuser только один официальный бот [@id470323695436_bot](https://max.ru/id470323695436_bot), который отправляет уведомления. Не доверяйте другим ботам, которые могут пытаться выдать себя за официального.

### Как привязать MAX

1. Перейдите в раздел **Настройки аккаунта** → **Нотификации**
2. В блоке **MAX** нажмите **Добавить аккаунт**
3. Выберите формат привязки: **Личный чат** или **Группа**
4. Отсканируйте QR-код или перейдите по ссылке для подтверждения

После привязки канал активируется сразу, и новые уведомления начнут отправляться в выбранный чат MAX.

---

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


# Уведомления на емейл

Доступные настройки и особенности работы

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Уведомления на емейл | да | да | да |

На всех тарифах действует ограничение 30 емейл-уведомлений в сутки — это защита доставляемости писем. Если уведомлений нужно больше, подключите Телеграм или MAX.

Сравнение тарифов: 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

---

Уведомления на емейл будут отправляться с ящика **info@statuser.cloud**.

> Иногда письма могут попадать в спам, поэтому рекомендуется добавить этот адрес в белый список вашего почтового клиента.

К аккаунту Statuser можно привязать **несколько емейл-адресов** — например, личную почту, корпоративную и общий ящик команды. Все подтверждённые адреса получают одинаковые уведомления о событиях мониторинга.

### Как добавить емейл

1. Перейдите в раздел [Настройки нотификаций](https://statuser.cloud/my/account/notifications).
2. Нажмите **«Добавить канал»** и выберите вкладку **«Емейл»**.
3. Введите адрес и нажмите **«Добавить емейл»** — на указанную почту придёт письмо с **6-значным кодом подтверждения**.
4. Введите код в открывшейся форме и нажмите **«Подтвердить»**. Готово — адрес появился в списке каналов.

Если письмо не пришло, нажмите **«Отправить код повторно»** — код можно перевыпускать не чаще одного раза в минуту. Срок жизни кода — 15 минут, после 5 неверных попыток код инвалидируется и нужно запросить новый.

### Как удалить емейл

В списке каналов наведите курсор на карточку нужного адреса и нажмите крестик в правом верхнем углу. Уведомления на этот ящик перестанут приходить сразу после удаления.

### Емейл аккаунта и емейл для уведомлений

Это две разные сущности:

- **Емейл аккаунта** — адрес, указанный при регистрации. Используется для входа, восстановления пароля, оповещений безопасности и квитанций об оплате. Изменить этот адрес сейчас самостоятельно нельзя.
- **Емейл для уведомлений** — список адресов, которые получают оповещения о падениях серверов, продлении SSL/доменов, превышении задержки и других событиях мониторинга. Управляется в разделе нотификаций и не пересекается с авторизацией.

При регистрации емейл аккаунта автоматически добавляется в список нотификаций — поэтому ничего настраивать не нужно.

> **Важно**
> Емейл уникален в пределах одного аккаунта: один и тот же адрес нельзя добавить дважды. При этом разные аккаунты Statuser могут использовать один общий ящик для уведомлений (например, если у вас несколько проектов с разными аккаунтами).

---

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


# Webhook-уведомления

Настройка эндпоинта, подпись запросов, структура и примеры тел запросов для всех типов уведомлений

> Индекс всей документации в 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 - это HTTP POST-запрос на ваш URL-эндпоинт при наступлении событий мониторинга и аккаунта.

Этот канал удобно использовать для интеграции с вашими системами: корпоративные чаты, внутренние сервис-дески, SIEM, внутренние панели и собственные автоматизации.

> На аккаунт можно добавить до **20** вебхуков. Для каждого вебхука можно
> отдельно выбрать, какие типы уведомлений отправлять.

## Как работает доставка

- Statuser отправляет `POST` c `application/json` на URL вебхука.
- Успешной доставкой считается только ответ с кодом `2xx`.
- Таймаут запроса: **7 секунд**.
- Редиректы **не поддерживаются** (`3xx` считается ошибкой доставки).
- Если у эндпоинта задан секрет, запрос подписывается заголовком `X-Statuser-Signature`.
- Для вебхука нужен публичный URL.

## Заголовки запроса

Каждый вебхук-запрос содержит следующие заголовки:

```http
Content-Type: application/json
User-Agent: Mozilla/5.0 (compatible; Statuser Webhook; https://statuser.cloud/)
X-Statuser-Event: service_unavailable
X-Statuser-Subscription-Type: service_alerts
X-Statuser-Signature: sha256=<hex>   // только если указан secret
```

Где:

- `X-Statuser-Event` - конкретный тип события (`notification_type`).
- `X-Statuser-Subscription-Type` - группа уведомлений (например, `service_alerts`, `dns_alerts`, `billing_alerts`).
- `X-Statuser-Signature` - HMAC-подпись тела запроса.

## Подпись секрета (HMAC SHA-256)

Если у вебхука заполнен секрет, Statuser:

1. Берет JSON body в строковом виде;
2. Считает HMAC SHA-256 по вашему `secret`;
3. Отправляет результат в виде `sha256=` в `X-Statuser-Signature`.

Проверка подписи на вашей стороне (Node.js):

```ts
import crypto from 'crypto';

function verifyStatuserSignature(
  rawBody: string,
  secret: string,
  header?: string
) {
  if (!header?.startsWith('sha256=')) return false;

  const received = header.slice('sha256='.length);
  const expected = crypto
    .createHmac('sha256', secret)
    .update(rawBody)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(received, 'hex'),
    Buffer.from(expected, 'hex')
  );
}
```

## Формат payload

Во всех вебхук-событиях есть базовые поля:

```json
{
  "notification_type": "service_unavailable",
  "subscription_type": "service_alerts",
  "created_at": "2026-02-16T10:21:30.000Z",
  "account_id": 42
}
```

Дополнительные поля зависят от `notification_type`.

## Контракты body по типам уведомлений

Ниже приведены примеры для каждого типа уведомлений, доступного в вебхуках.

#### Доступность сервисов

**service_unavailable**

```json
{
    "notification_type": "service_unavailable",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "API production",
      "host": "api.example.com",
      "protocol": "https"
    },
    "incident": {
      "id": 9001,
      "started_at": "2026-02-16T10:21:30.000Z",
      "ended_at": null,
      "status": "ongoing",
      "root_error": "http_5xx_error"
    }
}
```

**service_available_now**

```json
{
    "notification_type": "service_available_now",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "API production",
      "host": "api.example.com",
      "protocol": "https"
    },
    "incident": {
      "id": 9001,
      "started_at": "2026-02-16T10:21:30.000Z",
      "ended_at": "2026-02-16T10:35:30.000Z",
      "status": "completed",
      "root_error": "http_5xx_error"
    }
}
```

**heartbeat_unavailable**

```json
{
    "notification_type": "heartbeat_unavailable",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "Worker heartbeat",
      "host": "worker.example.com",
      "protocol": "heartbeat"
    },
    "incident": {
      "id": 9002,
      "started_at": "2026-02-16T10:21:30.000Z",
      "ended_at": null,
      "status": "ongoing",
      "root_error": "heartbeat_timeout"
    }
}
```

**heartbeat_available_now**

```json
{
    "notification_type": "heartbeat_available_now",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "Worker heartbeat",
      "host": "worker.example.com",
      "protocol": "heartbeat"
    },
    "incident": {
      "id": 9002,
      "started_at": "2026-02-16T10:21:30.000Z",
      "ended_at": "2026-02-16T10:29:30.000Z",
      "status": "completed",
      "root_error": "heartbeat_timeout"
    }
}
```

**service_slow_response**

```json
{
    "notification_type": "service_slow_response",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "API production",
      "host": "api.example.com",
      "protocol": "https"
    },
    "latency": {
      "trigger_ms": 1500,
      "recovery_ms": 900,
      "observed_max_ms": 2100,
      "slow_start_at": "2026-02-16T10:20:30.000Z"
    }
}
```

**service_response_recovered**

```json
{
    "notification_type": "service_response_recovered",
    "subscription_type": "service_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 101,
      "name": "API production",
      "host": "api.example.com",
      "protocol": "https"
    },
    "latency": {
      "trigger_ms": 1500,
      "recovery_ms": 900,
      "observed_max_ms": 2100,
      "slow_start_at": "2026-02-16T10:20:30.000Z",
      "recovery_at": "2026-02-16T10:25:00.000Z"
    }
}
```

#### Изменения DNS

**dns_records_changed**

```json
{
    "notification_type": "dns_records_changed",
    "subscription_type": "dns_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 102,
      "name": "DNS monitor",
      "host": "example.com",
      "protocol": "dns"
    },
    "dns": {
      "id": 501,
      "domain": "example.com",
      "record_type": "A",
      "change_type": "modified",
      "added_records": [
        "203.0.113.20"
      ],
      "removed_records": [
        "203.0.113.10"
      ],
      "created_at": "2026-02-16T10:21:28.000Z"
    }
}
```

#### Статус сертификатов

**ssl_expire_soon_14**

```json
{
    "notification_type": "ssl_expire_soon_14",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

**ssl_expire_soon_7**

```json
{
    "notification_type": "ssl_expire_soon_7",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

**ssl_expire_soon_3**

```json
{
    "notification_type": "ssl_expire_soon_3",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

**ssl_expire_soon_1**

```json
{
    "notification_type": "ssl_expire_soon_1",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

**ssl_expired**

```json
{
    "notification_type": "ssl_expired",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

**ssl_renew**

```json
{
    "notification_type": "ssl_renew",
    "subscription_type": "ssl_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 103,
      "name": "Main site",
      "host": "example.com",
      "protocol": "https"
    },
    "ssl": {
      "id": 300,
      "domain": "example.com",
      "valid_from": "2025-03-01T00:00:00.000Z",
      "valid_to": "2026-02-23T00:00:00.000Z",
      "issuer": "Let's Encrypt",
      "subject": "CN=example.com",
      "san": [
        "example.com",
        "www.example.com"
      ],
      "chain_valid": true,
      "errors": []
    }
}
```

#### Статус доменов

**domain_expire_soon_30**

```json
{
    "notification_type": "domain_expire_soon_30",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_expire_soon_14**

```json
{
    "notification_type": "domain_expire_soon_14",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_expire_soon_7**

```json
{
    "notification_type": "domain_expire_soon_7",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_expire_soon_3**

```json
{
    "notification_type": "domain_expire_soon_3",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_expire_soon_1**

```json
{
    "notification_type": "domain_expire_soon_1",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_expired**

```json
{
    "notification_type": "domain_expired",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

**domain_renew**

```json
{
    "notification_type": "domain_renew",
    "subscription_type": "domain_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "server": {
      "id": 104,
      "name": "Domain monitor",
      "host": "example.com",
      "protocol": "domain"
    },
    "domain": {
      "id": 610,
      "domain": "example.com",
      "register_at": "2020-02-10T00:00:00.000Z",
      "expire_at": "2026-03-18T00:00:00.000Z",
      "registrar": "REG-RU",
      "registrant_org": "Example LLC",
      "ns": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
}
```

#### Оплата и тариф

**plan_expire_soon_7**

```json
{
    "notification_type": "plan_expire_soon_7",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "expires_at": "2026-03-01T00:00:00.000Z",
    "expire_in_days": 7
}
```

**plan_expire_soon_3**

```json
{
    "notification_type": "plan_expire_soon_3",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "expires_at": "2026-03-01T00:00:00.000Z",
    "expire_in_days": 3
}
```

**plan_expire_soon_1**

```json
{
    "notification_type": "plan_expire_soon_1",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "expires_at": "2026-03-01T00:00:00.000Z",
    "expire_in_days": 1
}
```

**plan_expired**

```json
{
    "notification_type": "plan_expired",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "expires_at": "2026-03-01T00:00:00.000Z"
}
```

**plan_autopay_reminder**

```json
{
    "notification_type": "plan_autopay_reminder",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "card_last4": "4242",
    "amount": 2990,
    "billing_period": "month"
}
```

**plan_autopay_success**

```json
{
    "notification_type": "plan_autopay_success",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "billing_period": "month"
}
```

**plan_autopay_retry_1**

```json
{
    "notification_type": "plan_autopay_retry_1",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "retry_attempt": 1
}
```

**plan_autopay_retry_2**

```json
{
    "notification_type": "plan_autopay_retry_2",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "retry_attempt": 2
}
```

**plan_autopay_retry_3**

```json
{
    "notification_type": "plan_autopay_retry_3",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "plan_name": "Team",
    "retry_attempt": 3
}
```

**plan_downgrade_applied**

```json
{
    "notification_type": "plan_downgrade_applied",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "old_plan_id": 3,
    "new_plan_id": 1,
    "billing_period": "month"
}
```

**invoice_paid**

```json
{
    "notification_type": "invoice_paid",
    "subscription_type": "billing_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "invoice_id": 555,
    "invoice_url": "https://example.com/invoice/555"
}
```

#### Недельные отчеты

**weekly_report**

```json
{
    "notification_type": "weekly_report",
    "subscription_type": "weekly_reports",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "servers": [
      {
        "id": 101,
        "name": "API production",
        "host": "api.example.com",
        "uptime": 99.98,
        "uptime_diff": -0.02,
        "availability": [
          {
            "date": "2026-02-10",
            "uptime": 100
          }
        ]
      }
    ],
    "incidents": [
      {
        "id": 9001,
        "started_at": "2026-02-12T10:21:30.000Z",
        "ended_at": "2026-02-12T10:33:30.000Z",
        "status": "completed",
        "server_id": 101,
        "root_error": "http_5xx_error"
      }
    ],
    "incidents_total": 3,
    "report_date_from": "2026-02-09T00:00:00.000Z",
    "report_date_to": "2026-02-15T23:59:59.999Z",
    "report_id": "d23caacf-6151-4962-9c88-328b54411890",
    "report_url": "https://statuser.cloud/reports/d23caacf-6151-4962-9c88-328b54411890"
}
```

#### Идеи и обсуждения

**idea_votes_milestone_5**

```json
{
    "notification_type": "idea_votes_milestone_5",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 5
}
```

**idea_votes_milestone_10**

```json
{
    "notification_type": "idea_votes_milestone_10",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 10
}
```

**idea_votes_milestone_25**

```json
{
    "notification_type": "idea_votes_milestone_25",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 25
}
```

**idea_votes_milestone_50**

```json
{
    "notification_type": "idea_votes_milestone_50",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 50
}
```

**idea_votes_milestone_100**

```json
{
    "notification_type": "idea_votes_milestone_100",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 100
}
```

**idea_votes_milestone_200**

```json
{
    "notification_type": "idea_votes_milestone_200",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_votes_count": 200
}
```

**idea_comment_created**

```json
{
    "notification_type": "idea_comment_created",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "comment_id": 778,
    "comment_text": "Отличная идея, поддерживаю"
}
```

**idea_comment_reply**

```json
{
    "notification_type": "idea_comment_reply",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "comment_id": 778,
    "comment_text": "Отличная идея, поддерживаю"
}
```

**idea_status_changed**

```json
{
    "notification_type": "idea_status_changed",
    "subscription_type": "ideas",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "idea_id": 120,
    "idea_title": "Webhook retries",
    "idea_status": "planned",
    "idea_planned_date": "2026-03-10",
    "idea_is_author": false
}
```

#### Режим праздников

**holiday_mode_ended**

```json
{
    "notification_type": "holiday_mode_ended",
    "subscription_type": "holiday_mode",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42
}
```

#### API ключи

**api_key_expire_soon_3**

```json
{
    "notification_type": "api_key_expire_soon_3",
    "subscription_type": "api_key_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "api_key_id": 33
}
```

**api_key_expired**

```json
{
    "notification_type": "api_key_expired",
    "subscription_type": "api_key_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "api_key_id": 33
}
```

#### Безопасность

**new_login**

```json
{
    "notification_type": "new_login",
    "subscription_type": "security_alerts",
    "created_at": "2026-02-16T10:21:30.000Z",
    "account_id": 42,
    "login_at": "2026-02-16T10:20:00.000Z",
    "login_ip": "198.51.100.24",
    "login_user_agent": "Mozilla/5.0 ...",
    "login_time_zone": "Europe/Moscow"
}
```

---

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


# Еженедельные отчёты

Автоматические отчёты о проверках и инцидентах. Отправляются по понедельникам на емейл, в Телеграм и MAX

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Еженедельные отчёты | да | да | да |
| Уведомления по вебхукам | нет | нет | да |

Еженедельный отчёт приходит на всех тарифах на емейл, в Телеграм и MAX. Доставка отчёта в вебхук с подпиской weekly_reports требует тарифа Team.

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

---

Statuser предоставляет автоматическую отчётность по всем серверам, находившимся в мониторинге в течение предыдущей недели. Такой подход позволяет:

* централизованно отслеживать стабильность инфраструктуры;
* выявлять паттерны и повторяющиеся сбои;
* документировать надёжность сервисов для внутренних и внешних аудитов.

Еженедельные отчёты формируются и отправляются **по понедельникам в 11:00 по московскому времени (UTC+3)**:

* на все подтверждённые емейл, привязанные к аккаунту;
* в подключенные телеграм аккаунты;
* в подключенные MAX аккаунты;
* в подключенные вебхуки с подпиской `weekly_reports`.

Сам отчёт приходит на всех тарифах. Доставка в вебхук — только на тарифе Team.

> **Примечание**
> Отчёт содержит агрегированные данные за последнюю календарную неделю по всем серверам, которые были активны в мониторинге.
> Если в течение недели ни один сервер не находился в мониторинге, отчёт не формируется.

### Общая статистика

* Общее количество зафиксированных инцидентов;
* Пять наиболее продолжительных инцидентов:

    * описание причины сбоя;
    * дата и время начала;
    * длительность простоя в минутах.

Эти данные позволяют быстро оценить критичность событий и приоритеты для последующего анализа.

### Аптайм по каждому серверу

Для каждого сервера предоставляется:

* процент аптайма за неделю (в формате `99.98%`);
* таблица с ежедневным статусом:
* доступен или недоступен в течение каждого дня.

Это даёт объективное представление о стабильности сервиса с разбивкой по дням и помогает выявить повторяющиеся сбои.

---

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


# Режим праздников

Временное отключение уведомлений о мониторинге во время праздников, отпуска или технических работ

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

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

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

| Функция | 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

---

Режим праздников позволяет временно приостановить все уведомления о мониторинге. Это полезно во время отпуска, праздников или планируемых технических работ, когда вы не хотите получать уведомления о сбоях.

> Мониторинг серверов и сбор данных продолжаются в обычном режиме — отключаются
> только уведомления. Вы сможете посмотреть статистику за период праздников
> после их окончания.

Когда режим активен:

- **Уведомления приостанавливаются** — не приходят ни емейлы, ни Телеграм сообщения, ни события в вебхуки
- **Мониторинг продолжается** — серверы проверяются по расписанию, данные собираются
- **Инциденты фиксируются** — все сбои сохраняются в системе
- **Тестовые уведомления работают** — можно проверить настройки, не дожидаясь окончания режима

### Завершение режима

Режим праздников автоматически отключается в указанную дату и время. После этого все уведомления возобновляются.

Также вы можете отключить режим вручную в любое время до запланированного окончания.

### Индикация в интерфейсе

Пока режим праздников активен, в верхней части интерфейса отображается индикатор с иконкой и временем окончания режима праздников.

> Режим праздников применяется ко всем серверам аккаунта. Нельзя настроить
> частичное отключение уведомлений только для некоторых серверов.

---

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


# Создание страницы статуса

Настройка публичной страницы для отображения статуса ваших сервисов

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Количество страниц статуса | 1 страница | 3 страницы | 20 страниц |
| Собственный брендинг страницы | да | да | да |
| Свой домен для страницы | нет | да | да |
| White Label | нет | нет | да |
| Доступ по паролю | нет | нет | да |
| Исключение из поисковых систем | нет | нет | да |
| Минимальная длительность инцидента | нет | да | да |
| Хранение инцидентов | 7 дней | 60 дней | 180 дней |

Создать страницу можно на любом тарифе, но их количество и часть продвинутых настроек из шага 4 зависят от тарифа. Максимальный период истории на странице ограничен сроком хранения инцидентов.

Сравнение тарифов: 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

---

Для создания публичной страницы статуса нажмите **Создать страницу** в разделе **Страницы статуса**.

Это позволит вам опубликовать страницу со статусом ваших сервисов и серверов.

#### Шаги создания страницы

1. **Название страницы**

   Укажите название вашей компании или сервиса — оно будет отображаться в заголовке страницы. Например: `Statuser` или `Status Page for App X`.

2. **Домен и адрес страницы**

   Вы можете выбрать размещение страницы на общем домене Statuser (`up.statuser.cloud`) или подключить свой собственный домен. В первом случае достаточно ввести путь — часть URL, например: `my-company`, и страница будет доступна по адресу:

   ```
   https://up.statuser.cloud/s/my-company
   ```

> Подключение собственного домена будет доступно через отдельную вкладку.
> После настройки потребуется добавить DNS-записи.

3. **Кастомизация страницы**

   Вы можете загрузить **логотип** и **фавикон**, чтобы оформить страницу в стиле вашего бренда.

   Также можно указать:

   - URL сайта компании (например: `https://example.com`)
   - Емейл или форму для обратной связи (`mailto:support@example.com`)

4. **Продвинутые настройки**

   - **Разрешить индексирование поисковиками** — если включено, страница может быть проиндексирована Google, Yandex и другими системами.

> Если отключить индексацию, то страница статуса будет приватной и доступна
> только по ссылке.

    - **Скрыть бренд Statuser** — страница не будет содержать логотип и ссылку на Statuser в подвале.
   - **Защитить паролем** — можно ограничить доступ к странице только для авторизованных пользователей.
   - **Минимальная длительность инцидента** — короткие инциденты (например, до 30 секунд) можно не показывать на публичной странице.
   - **Точность аптайма** — выбор количества знаков после запятой для отображения процента аптайма.
   - **Тема страницы** — всегда светлая, всегда тёмная или выбор темы посетителем.
   - **Часовой пояс страницы** — влияет на отображение времени и разбиение событий по дням.
   - **Если не в мониторинге → доступен** — статус "Не в мониторинге" будет отображаться как "Доступен".
   - **Период истории на странице** — выбор диапазона отображения (7/14/30/60/90/180 дней). Максимальный период зависит от срока хранения инцидентов на текущем тарифе.

5. **Сохранение**

   После заполнения формы нажмите **Создать страницу** — страница статуса будет опубликована и доступна по выбранному адресу.

> Вы можете создать несколько страниц статуса — например, отдельно для клиентов,
> партнёров и внутреннего использования.

После создания страницы вы сможете вести публичную коммуникацию по инцидентам во вкладке **Публичные отчёты**. Подробнее в статье [Публикация и ведение отчётов](/docs/status-page-reports-management).

---

Источник: https://statuser.cloud/docs/add-status-page


# Сервера и группы на странице статуса

Связь серверов с публичной страницей статуса

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Количество страниц статуса | 1 страница | 3 страницы | 20 страниц |

Сравнение тарифов: 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

---

После создания страницы статуса вы можете настроить её структуру — добавить группы и привязать к ним сервера. Это определяет, что именно увидят пользователи на опубликованной странице.

#### Что такое группа?

Группа — это логический блок, объединяющий связанные между собой сервисы. Например: «Серверы приложений», «Базы данных», «Сервисы в EU».

#### Добавление группы

1. Откройте редактор страницы статуса и перейдите на вкладку **Серверы**.
2. Нажмите **Добавить группу**.
3. Укажите:

   - **Название группы** — это будет отображаться заголовком на публичной странице.
   - **Описание** — отображается при наведении на иконку подсказки рядом с названием группы.

#### Добавление серверов в группу

1. Внутри группы нажмите **Добавить сервер**.
2. Выберите сервер из выпадающего списка. Он должен быть предварительно добавлен в ваш аккаунт.

> **Важно**
> Серверы с типом мониторинга DNS нельзя добавить на страницу статуса — они
> отслеживают изменения в DNS-записях, а не доступность сервиса.

3. Настройте:

   - **Публичное название** — как этот сервер будет называться на странице статуса. Можно не указывать: в этом случае будет использовано название сервера из вашего аккаунта.
   - **Комментарий** (необязательно) — отображается при наведении на подсказку рядом с сервером.

> Один и тот же сервер может быть использован в нескольких группах или даже на
> разных страницах статуса.

#### Удаление группы или сервера

- Чтобы удалить группу — нажмите **Удалить группу** справа от её заголовка.
- Чтобы убрать сервер из группы — нажмите иконку корзины рядом с названием сервера.

#### Сохранение изменений

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

> Если вы пока не хотите публиковать страницу, можно сохранить структуру и снять
> её с публикации — кнопка доступна сверху.

---

Источник: https://statuser.cloud/docs/status-page-servers-groups


# Кастомизация страницы статуса

Изменение логотипа, домена и оформления

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Собственный брендинг страницы | да | да | да |
| Свой домен для страницы | нет | да | да |
| White Label | нет | нет | да |
| Минимальная длительность инцидента | нет | да | да |
| Хранение инцидентов | 7 дней | 60 дней | 180 дней |

Логотип, фавикон, тема, точность аптайма и часовой пояс настраиваются на всех тарифах. Свой домен подключается с тарифа Pro, White Label — на 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

---

Вы можете изменить внешний вид страницы статуса, чтобы она соответствовала вашему бренду. Это помогает сделать страницу узнаваемой и более доверительной для пользователей.

#### Логотип и фавикон

1. Загрузите логотип вашей компании. Он будет отображаться в шапке страницы.
2. Добавьте фавикон — значок, который отображается на вкладке браузера.

#### Название и ссылки

* **Название страницы** — отображается в заголовке и заголовке браузера.
* **URL сайта компании** — будет являться ссылкой при клике на логотип или название вашей компании.
* **URL для обратной связи** — емейл или ссылка, которая будет открываться при клике на кнопку **Связаться**.

#### Собственный домен

_Доступно в тарифах Pro и Team_

Вы можете подключить собственный домен, чтобы страница выглядела как часть вашего сайта.

1. Перейдите в настройки статус страницы.
2. Укажите желаемое доменное имя.
3. Настройте CNAME, чтобы он вел на `up.statuser.cloud`.
4. Дождитесь прохождения проверки и подтверждения.

> После успешной настройки страница будет доступна по вашему домену. Также останется доступ по системному адресу `up.statuser.cloud/s/`.

#### Вайт лейбл

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

Вы сможете скрыть упоминание Statuser на странице — логотип, футер и другие элементы бренда платформы.

#### Настройки отображения

В настройках страницы доступен отдельный блок с параметрами отображения:

* **Период истории** — 7, 14, 30, 60, 90 или 180 дней.
* **Если не в мониторинге → доступен** — статус "Не в мониторинге" отображается как "Доступен".

> Максимальный период истории зависит от вашего тарифа и срока хранения инцидентов.

#### Тема, аптайм и часовой пояс

Дополнительно вы можете управлять тем, как данные выглядят для посетителей:

* **Тема страницы** — всегда светлая, всегда тёмная или выбор темы самим посетителем.
* **Точность аптайма** — от 0 до 4 знаков после запятой в процентах аптайма.
* **Часовой пояс страницы** — используется в таймлайнах, карточках событий и отметке времени последнего обновления.

#### Фильтрация коротких инцидентов

Если включить настройку **Минимальная длительность инцидента**, инциденты короче выбранного порога не будут отображаться на странице статуса.

---

Источник: https://statuser.cloud/docs/status-page-customization


# Публичность и доступ

Индексация и приватные страницы

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Доступ по паролю | нет | нет | да |
| Исключение из поисковых систем | нет | нет | да |

Сама страница статуса и её публичный адрес работают на любом тарифе. Тариф нужен именно для ограничения доступа: пароль и запрет индексации доступны на 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

---

Вы можете контролировать, кто и как может получить доступ к вашей странице статуса. Это позволяет использовать страницу как в публичных, так и во внутренних сценариях.

#### По умолчанию

Страница статуса доступна по уникальному URL, например:

```
https://up.statuser.cloud/s/your-company
```

Если вы не ограничили доступ — страница открыта для всех. В верхней части отображается текущий статус, а ниже — список групп и серверов с графиками доступности и аптаймом.

#### Индексация в поисковых системах

В настройках страницы можно включить или отключить индексацию поисковыми системами. Если отключено — страница не будет попадать в результаты Google и других поисковиков.

> Если вы используете страницу только внутри команды или хотите временно скрыть её из публичного доступа — рекомендуем отключить индексацию.

#### Доступ по паролю

Для ограничения доступа можно включить защиту страницы паролем:

1. Перейдите в настройки страницы статуса
2. Активируйте опцию **Защитить паролем**
3. Установите пароль, который потребуется для входа

После этого при переходе по ссылке пользователь увидит форму ввода пароля. Без него страница будет недоступна.

Ограничение распространяется на все публичные разделы страницы статуса:

- вкладку **Статус сервисов**
- вкладку **Инциденты** с публичными отчётами

> Пароль можно изменить или снять в любое время. Используйте это, если хотите открыть доступ партнёрам, не публикуя страницу полностью.

---

Источник: https://statuser.cloud/docs/status-page-visibility


# Интерфейс для посетителей

Что видят внешние посетители вашей странице статуса

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Количество страниц статуса | 1 страница | 3 страницы | 20 страниц |
| Публичные отчёты об инцидентах | 1 отчёт в месяц | 1 отчёт в месяц | Без ограничений |
| Плановые работы | 1 работы в месяц | 1 работы в месяц | Без ограничений |
| Объявления | нет | да | да |
| Доступ по паролю | нет | нет | да |

Так страница выглядит на любом тарифе. От тарифа зависит, появятся ли на ней объявления, публичные отчёты без лимита и форма входа по паролю.

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

---

Публичная страница статуса помогает пользователям самостоятельно проверить состояние сервисов без обращения в поддержку.

На странице есть три вкладки:

- **Статус сервисов** — текущая доступность, аптайм и история по дням
- **Инциденты** — архив публичных отчётов и детальные страницы по каждому отчёту
- **Плановые работы** — архив запланированных и выполненных работ с детальной хронологией

#### Главный блок статуса

В верхней части отображается общий статус страницы: всё работает, есть деградация, частичная или полная недоступность.

Данные обновляются автоматически каждые 30 секунд, поэтому посетитель видит актуальное состояние без ручного обновления.

#### Группы и сервисы

Сервисы отображаются внутри настроенных групп. Для каждого сервиса показываются:

- текущее состояние
- аптайм за выбранный период
- дневная лента доступности

Каждая колонка в ленте соответствует отдельному дню. Цвета показывают характер проблем (например, недоступность или деградация).

#### Детали дня

При наведении на день открывается карточка с деталями:

- аптайм за сутки
- интервалы сбоев
- длительность каждого интервала
- таймлайн по времени суток

Время отображается в часовом поясе, который задан в настройках страницы статуса.

#### Какие статусы бывают

На странице есть два уровня статусов: общий статус всей страницы и статус каждого отдельного сервиса. Ниже — что означает каждый вариант.

**Статус всей страницы:**

| Статус              | Что означает                                  |
|---------------------|-----------------------------------------------|
| `operational`       | 🟢 Все сервисы работают                       |
| `degraded`          | 🟡 Есть деградация без активной недоступности |
| `partial_outage`    | 🟠 Часть сервисов недоступна                  |
| `major_outage`      | 🔴 Все сервисы на странице недоступны         |
| `under_maintenance` | 🔵 Режим плановых работ                       |

**Статус конкретного сервиса:**

| Статус          | Что означает                                                     |
| --------------- | ---------------------------------------------------------------- |
| `operational`   | Сервис доступен                                                  |
| `downtime`      | Сервис недоступен                                                |
| `degraded`      | Сервис работает с деградацией                                    |
| `not_monitored` | Для периода нет мониторинга (или отображается как operational)   |

Если в настройках включена опция **Если не в мониторинге -> доступен**, состояние `not_monitored` в интерфейсе сервиса показывается как рабочее.

#### Публичные отчёты и плановые работы

Публичные отчёты по инцидентам показываются во вкладке **Инциденты**. Отмеченные в отчёте статусы сервисов влияют на то, что видят посетители:

- активная деградация в отчёте показывает сервис как деградированный
- завершённые (`resolved`) и нейтральные (`not_affected`) состояния не считаются активной деградацией
- недоступность (`downtime`) в блоке статуса сервисов формируется по активным инцидентам мониторинга

Подробнее в статье [История инцидентов для посетителей](/docs/status-page-public-reports).

Для плановых работ есть отдельный архив и карточка каждой записи. Активные работы отображаются состоянием `under_maintenance` для затронутых сервисов.

Подробнее в статье [Плановые работы](/docs/status-page-planned-maintenances).

#### Приватные страницы

Если страница защищена паролем, сначала отображается форма входа. После успешного ввода пароля посетителю доступны все вкладки: **Статус сервисов**, **Инциденты** и **Плановые работы**.

---

Источник: https://statuser.cloud/docs/status-page-view


# История инцидентов для посетителей

Список отчётов, детальная страница инцидента и влияние статусов отчёта на публичное отображение

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Публичные отчёты об инцидентах | 1 отчёт в месяц | 1 отчёт в месяц | Без ограничений |

Сравнение тарифов: 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

---

Публичные отчёты об инцидентах показывают посетителям, что именно происходит с сервисами, как развивается ситуация и когда проблема устранена.

Отчёты доступны на публичной странице статуса во вкладке **Инциденты**.

#### Что видит посетитель

Во вкладке **Инциденты** отображается архив отчётов по месяцам:

- карточка отчёта с текущим статусом (`Недоступность`, `Деградация`, `Исправлено`)
- время начала инцидента
- последнее опубликованное событие
- превью сообщения из последнего события

Если отчётов в выбранном месяце нет, показывается пустое состояние.

#### Окно архива

Архив листается по окнам по 3 месяца:

- можно перейти к более ранним месяцам
- вернуться к текущему окну
- развернуть длинный список отчётов за месяц кнопкой **Показать ещё**

#### Детальная страница отчёта

Клик по карточке открывает страницу отчёта. На странице доступны:

- заголовок и текущий статус отчёта
- время начала с привязкой к часовому поясу страницы
- список затронутых сервисов
- история событий (таймлайн)

#### История событий (таймлайн)

Таймлайн включает:

- стартовое событие (первичная публикация отчёта)
- последующие обновления статуса
- финальное состояние (например, `Исправлено`)

Текст событий поддерживает Markdown, поэтому в отчётах можно использовать:

- заголовки и списки
- ссылки
- кодовые блоки

#### Как отчёты влияют на отображение статуса

Статусы сервисов из отчётов используются в публичной выдаче:

- активный `degraded` в отчёте помечает сервис как деградированный
- `resolved` и `not_affected` не считаются активной деградацией
- состояние `downtime` сервиса на публичной странице определяется активными инцидентами мониторинга

Это влияет не только на карточку отчёта, но и на общий вид публичной страницы (вкладка **Статус сервисов** и история по дням).

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

Если страница статуса защищена паролем, вкладка **Инциденты** также доступна только после авторизации.

> Публичные отчёты не создаются посетителями страницы. Их публикует владелец страницы статуса из личного кабинета.

---

Источник: https://statuser.cloud/docs/status-page-public-reports


# Плановые работы

Создание, ведение и публикация плановых работ на публичной странице статуса

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Плановые работы | 1 работы в месяц | 1 работы в месяц | Без ограничений |

Сравнение тарифов: 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

---

Плановые работы помогают заранее предупредить клиентов о технических изменениях и спокойно объяснить, что происходит с сервисами во время обслуживания.

Если вы заранее знаете о работах, лучше оформить их именно здесь, а не ждать, пока пользователи начнут писать в поддержку.

#### Где находится раздел

У владельца страницы статуса есть отдельный раздел **Плановые работы** в панели управления.

У посетителей эта информация отображается на публичной странице во вкладке **Плановые работы**.

#### Как создать запись

Чтобы запланировать работы, откройте нужную страницу статуса и нажмите **Запланировать работы**.

В форме нужно указать:

1. **Название работ** — коротко и понятно, что именно будет происходить.
2. **Описание** — что меняется, чего ожидать пользователям и будут ли ограничения.
3. **Время начала** — когда работы должны стартовать.
4. **Время завершения** — когда работы должны закончиться.
5. **Затрагиваемые сервисы** — какие именно сервисы будут отмечены как участвующие в работах.

После сохранения откроется отдельная страница записи, где можно публиковать обновления по ходу работ.

> Черновик формы сохраняется автоматически в браузере. Если вы случайно закрыли страницу, текст можно будет восстановить.

#### Что происходит дальше

У каждой записи есть своё состояние:

- **Запланировано** — работы ещё не начались
- **В процессе** — работы уже идут
- **Завершено** — работы закончены

Статус меняется автоматически по указанному времени начала и завершения.

Если работы уже идут, затронутые сервисы на публичной странице помечаются как находящиеся на обслуживании. Это помогает посетителям сразу понять, что проблема ожидаемая и связана с плановыми изменениями.

#### Обновления во время работ

На странице записи можно публиковать новые сообщения в таймлайн:

- сообщить, что работы начались
- предупредить о временных ограничениях
- дать промежуточный статус
- сообщить о завершении

Первое сообщение создаётся автоматически из описания работ. Дальше вы можете добавлять новые обновления вручную.

Если нужно быстро закрыть запись, используйте кнопку **Опубликовать и завершить работы**. Она одновременно добавит сообщение и переведёт работы в завершённое состояние.

#### Что увидят посетители

На публичной странице посетители увидят:

- архив плановых работ по месяцам
- карточку каждой записи со статусом и расписанием
- список затронутых сервисов
- полную историю обновлений на отдельной странице

Это особенно удобно, если нужно заранее предупредить о релизе, миграции, обновлении инфраструктуры или коротком окне обслуживания.

#### Если страница закрыта паролем

Если страница статуса защищена паролем, вкладка **Плановые работы** тоже будет доступна только после входа.

---

Источник: https://statuser.cloud/docs/status-page-planned-maintenances


# Объявления

Баннеры-плашки сверху страницы статуса: создание, тип, период показа и отображение для посетителей

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

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

Доступно в тарифах Pro и 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

---

Объявления — это плашки-баннеры сверху страницы статуса. Они помогают быстро сообщить посетителям о проблеме, предстоящих работах или важном событии, не дожидаясь, пока пользователи начнут писать в поддержку.

В отличие от плановых работ и инцидентов, объявление не привязано к конкретным сервисам и не ведёт таймлайн — это короткое сообщение, которое видно всем посетителям страницы.

#### Где находится раздел

У владельца страницы статуса есть отдельный раздел **Объявления** в панели управления.

Посетители видят активные объявления плашкой сверху на всех публичных страницах статуса — и на главной, и в разделах с инцидентами и плановыми работами.

#### Как создать объявление

Откройте нужную страницу статуса, перейдите в раздел **Объявления** и нажмите **Создать объявление**.

В форме нужно указать:

1. **Заголовок** — коротко, о чём объявление.
2. **Тип** — важность: **Информация**, **Предупреждение** или **Проблема**. От типа зависит цвет плашки (синий, жёлтый и красный соответственно).
3. **Текст** — что произошло и как это влияет на пользователей.
4. **Ссылка** — необязательная ссылка с подробностями. Если её указать, в баннере появится кнопка **Подробнее**.
5. **Период показа** — необязательное окно времени.

> Черновик формы сохраняется автоматически в браузере. Если вы случайно закрыли страницу, текст можно будет восстановить.

#### Период показа

Если **период показа не задан**, объявление видно сразу после создания и до тех пор, пока вы его не удалите или не завершите вручную.

Если включить **Ограничить период показа**, можно задать время начала и окончания. Объявление появится и исчезнет на публичной странице точно в указанные моменты — заранее запланированное объявление не будет видно посетителям раньше времени.

#### Состояния объявления

У каждого объявления есть состояние, которое определяется периодом показа:

- **Запланировано** — время начала ещё не наступило
- **Активно** — объявление показывается посетителям
- **Завершено** — время окончания прошло

Активное объявление можно остановить досрочно — в форме редактирования есть кнопка **Завершить показ**. Она выставит время окончания текущим моментом, и плашка сразу перестанет показываться.

#### Редактирование и удаление

Клик по объявлению в списке открывает форму редактирования. Через меню действий можно удалить объявление — это необратимо.

#### Что увидят посетители

Активное объявление показывается полупрозрачной плашкой во всю ширину сверху страницы. Цвет соответствует типу, рядом с текстом — кнопка **Подробнее** (если задана ссылка) и крестик, чтобы скрыть плашку. Если посетитель закрыл объявление, оно больше не появится в этом браузере, пока остаётся активным.

---

Источник: https://statuser.cloud/docs/status-page-announcements


# Подписчики

Подписка посетителей по емейл или через RSS/Atom: подтверждение, письма об инцидентах и работах, управление списком и отписка

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Подписчики | нет | нет | до 500 подписчиков |

Сравнение тарифов: 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

---

Подписчики — это посетители, которые оставили свой емейл на странице статуса, чтобы получать письма о происходящем. Так о проблеме узнают даже те, кто не открывает страницу статуса каждый день.

В отличие от объявлений, плановых работ и отчётов, подписчиков добавляет не владелец, а сами посетители — они подписываются на публичной странице.

#### Где находится раздел

У владельца страницы статуса есть отдельный раздел **Подписчики** в панели управления. В нём виден список подписчиков, их статус и сводка: сколько подтвердили подписку и сколько ещё ожидают подтверждения.

Приём подписчиков нужно включить: в настройках страницы, в блоке **Продвинутые настройки**, есть переключатель **Подписка для посетителей**. Пока он выключен, кнопка подписки на публичной странице не показывается.

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

#### Как посетитель подписывается

1. Посетитель нажимает **Подписаться** и вводит свой емейл.
2. На этот адрес приходит письмо со ссылкой подтверждения.
3. После перехода по ссылке подписка становится активной.

> Подписка работает по схеме двойного подтверждения (double opt-in): пока посетитель не перейдёт по ссылке из письма, писем он не получает. Это защищает от подписки чужих адресов и спама.

#### Какие письма получают подписчики

Подтверждённые подписчики получают письма о ключевых событиях страницы статуса:

- **Инциденты** — когда вы публикуете новый отчёт об инциденте и когда добавляете в него обновления.
- **Плановые работы** — когда вы создаёте плановые работы и публикуете по ним обновления.

В каждом письме есть ссылка отписки — посетитель может отписаться в один клик в любой момент.

#### Имя отправителя и адрес для ответов

В настройках страницы, рядом с переключателем **Подписка для посетителей**, можно задать **имя отправителя** (например, «Acme Status») и **адрес для ответов** (Reply-To) — тогда ответы подписчиков будут приходить на вашу почту. Сам адрес отправки при этом не меняется: письма уходят с общего адреса рассылки, чтобы сохранить высокую доставляемость.

#### RSS и Atom

Кроме писем, за обновлениями можно следить через ленту **RSS** или **Atom** — это удобно тем, кто пользуется читалками или собирает статусы нескольких сервисов в одном месте. В отличие от емейл, лента не требует подтверждения и не собирает никаких данных о посетителе.

Ссылки на ленту посетитель найдёт в том же окне подписки — по кнопке подписки в шапке. Лента содержит те же события, что и письма: инциденты и плановые работы.

#### Состояния подписки

У каждой записи в списке есть статус:

- **Подтверждён** — посетитель перешёл по ссылке и получает письма
- **Ожидает** — письмо с подтверждением отправлено, но ссылку ещё не открыли
- **Истекла** — подписку не подтвердили за 48 часов; такая запись не занимает лимит, а посетитель может подписаться заново
- **Отписан** — посетитель отписался по ссылке из письма

#### Управление списком

В разделе **Подписчики** список можно фильтровать по статусу, искать по емейл и сортировать. Подписчиков можно выгрузить в CSV кнопкой **Экспорт CSV** или удалить через меню действий — удалённый подписчик перестаёт получать письма, а подписаться снова сможет только сам.

#### Лимит подписчиков

На каждой странице статуса может быть до **500 активных подписчиков** — подтверждённых и ожидающих подтверждения. При достижении лимита новые подписки перестают приниматься, а все текущие подписчики продолжают получать письма как обычно.

> Лимит может быть расширен индивидуально по запросу.

---

Источник: https://statuser.cloud/docs/status-page-subscribers


# Публикация и ведение отчётов

Работа с отчётами в кабинете: создание, фильтрация, публикация событий и редактирование

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Публичные отчёты об инцидентах | 1 отчёт в месяц | 1 отчёт в месяц | Без ограничений |

Сравнение тарифов: 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

---

Публичные отчёты создаются в кабинете владельца страницы статуса и публикуются для клиентов во вкладке **Инциденты**.

#### Что можно делать в разделе

В разделе **Публичные отчёты** доступны:

- создание нового отчёта
- фильтрация по статусам (`Недоступен`, `Деградация`, `Исправлено`)
- поиск по заголовку
- сортировка (по дате, названию, количеству событий)
- редактирование и удаление отчёта

#### Как создать отчёт

Нажмите **Создать отчёт** и заполните форму:

1. Заголовок
2. Первое сообщение
3. Время начала
4. Затронутые сервисы

Есть 2 сценария создания:

- **Выбрать инциденты** - сервисы и время старта подставляются из выбранных активных инцидентов
- **Настроить вручную** - статусы сервисов отмечаются вручную

#### Статусы сервисов в отчёте

Для каждого сервиса можно задать:

- `downtime` - недоступен
- `degraded` - деградация
- `resolved` - исправлено (для обновлений)
- `not_affected` - не затронут

В payload отправляются только сервисы, отличные от `not_affected`.

#### Работа с карточкой отчёта

У каждого отчёта есть отдельная страница в кабинете. На ней можно:

- публиковать новые события в таймлайн
- менять статусы сервисов для нового события
- редактировать текст и время отдельных событий
- удалять события (кроме стартового)
- редактировать заголовок и время начала отчёта
- удалить отчёт целиком

#### Публикация обновления

При публикации нового события:

- сообщение вводится в markdown-редакторе
- статусы сервисов задаются на момент публикации события
- событие сразу появляется в публичном отчёте

Если для всех сервисов указать `resolved`, отчёт перейдёт в состояние **Исправлено**.

---

Источник: https://statuser.cloud/docs/status-page-reports-management


# Виджет статуса

Встраиваемый виджет для отображения статуса на вашем сайте

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Количество страниц статуса | 1 страница | 3 страницы | 20 страниц |
| Доступ по паролю | нет | нет | да |

Виджет доступен на всех тарифах, но работает только для страниц без парольной защиты.

Сравнение тарифов: 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

---

Виджет статуса (badge) — это небольшой блок для встраивания на сайт. Он показывает **текущий статус** страницы статуса и ведёт по ссылке на неё.

Настройки виджета доступны во вкладке **Виджет** на странице статуса. Там можно выбрать режим встраивания, язык, тему, размер и оформление.

Виджет поддерживает два режима встраивания: **script** и **iframe**. Режим script встраивает виджет как часть страницы и лучше подходит для гибкой интеграции. Iframe изолирует виджет от CSS и JavaScript сайта и удобен, если есть ограничения по стилям или безопасности.

> Виджет работает только для публичных страниц статуса. Если включена парольная защита, виджет будет недоступен.

Тема `Auto` автоматически подстраивается под системную тему пользователя.

Статус в виджете обновляется автоматически с интервалом **5 секунд**.

---

Источник: https://statuser.cloud/docs/status-page-widget


# Тарифы и лимиты

Перечень тарифных планов Statuser и разбор основных лимитов и отличий между ними

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

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

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

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

---

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

> Страница тарифов с актуальными ценами и сравнениями доступна на [отдельной странице](/pricing).

### Доступные планы

| Тариф | Основные возможности                                                                                                                     |
|-------|------------------------------------------------------------------------------------------------------------------------------------------|
| **Free** | Базовый мониторинг для небольших проектов — HTTP, Ping, TCP, 2 региона проверок, история 7 дней. |
| **Pro** | Всё из Free + частота проверок от 1 минуты, 5 регионов, мониторинг SSL/доменов, DNS и поиск текста, свои коды успешного HTTP-ответа, история 60 дней. |
| **Team** | Всё из Pro + расширенные лимиты, белый лейбл статус-страниц, до 20 страниц статуса, история 180 дней и вебхук-уведомления.               |

Если стандартных планов недостаточно, можно обсудить **кастомные условия** с нашей командой по почте info@statuser.cloud.

## Чем они отличаются

Каждый тариф в Statuser не просто отличается ценой — он предлагает разный набор возможностей и разные ограничения. Чтобы выбрать подходящий план, ориентируйтесь на важные параметры:

### Основные параметры тарифов

- **Частота проверок**
  Насколько часто Statuser проверяет ваши сервисы. Чем выше частота (например, 1 минута вместо 5), тем точнее и быстрее вы будете узнавать о проблемах.

- **Количество сервисов под мониторингом**
  Сколько отдельных ресурсов (сайтов, API, портов и т. д.) вы можете отслеживать одновременно.

- **Региональные проверки**
  Возможность проверять доступность с разных точек мира. Это помогает понять, где именно возникают проблемы.

- **История данных и инцидентов**
  Длительность хранения истории доступности и событий. Больше истории — удобнее анализировать тренды.

- **Статус-страницы**
  Возможность создавать публичные страницы с информацией о статусе ваших сервисов. В старших тарифах доступны дополнительные настройки и белый лейбл.

- **Дополнительные функции**
  Например, ИИ анализ инцидентов, комментарии к инцидентам и др.

Коротко: чем выше тариф — тем больше возможностей, лимитов и контроля над мониторингом.

> На всех тарифах есть ограничение на **30 емейл-уведомлений в сутки**.
> Это ограничение введено для того, чтобы письма не попадали в спам и сохраняли свою доставляемость.
> Если вам нужно больше уведомлений, используйте **Телеграм** или **MAX** — на отправку уведомлений в эти каналы нет никаких ограничений.

### Пример влияния лимитов на работу

| Ситуация                                      | Важно учитывать |
|-----------------------------------------------|-----------------|
| У вас 50 сайтов и API                         | нужен тариф с большим лимитом сервисов |
| Нужна максимальная точность                   | выбирайте тариф с частотой проверок 1 минута |
| Требуется анализ истории за несколько месяцев | тариф с длительным хранением данных |

### Почему это важно

Понимание различий и лимитов помогает:

- выбрать тариф под масштаб вашего проекта
- избежать неожиданных ограничений после подключения
- оценить затраты и выгоду от каждого уровня

---

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


# Смена тарифа

Апгрейд и даунгрейд, момент вступления в силу и перерасчёты при смене тарифа

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

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

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

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

---

Сменить тариф в Statuser можно в любой момент в панели управления в разделе [Тарифы и оплата](https://statuser.cloud/my/account/billing).

Ниже — как работает смена тарифа: апгрейд, даунгрейд, с какого момента применяется и как считается доплата.

## Переход на более дорогой тариф

Апгрейд применяется **сразу после оплаты доплаты**.

- новый тариф начнёт действовать сразу
- сумма к оплате рассчитывается как разница между тарифами за оставшийся оплаченный период

### Как считается доплата

Если у вас уже есть активный оплаченный тариф, при апгрейде рассчитывается доплата за оставшиеся дни до конца текущего периода.

Если одновременно меняется период оплаты (например, переход на год), доплата рассчитывается так:

- берётся **полная стоимость** нового тарифа за выбранный период
- из неё вычитается «кредит» за неиспользованные дни текущего тарифа

> Для расчёта используется оставшееся время до окончания текущего тарифа.
> Поэтому доплата может отличаться в зависимости от того, сколько дней осталось
> до окончания.

## Переход на более дешёвый тариф

Даунгрейд применяется **не сразу**, а **после окончания уже оплаченного периода** текущего тарифа.

- до даты окончания у вас продолжит действовать текущий тариф
- новый (более дешёвый) тариф будет запланирован и применится автоматически в конце периода

Пока даунгрейд запланирован, в разделе **Тарифы и оплата** отображается карточка «Запланировано изменение тарифа» с датой применения.

### Отмена запланированного даунгрейда

Запланированный даунгрейд можно отменить.

Если следующий период уже был оплачен по сниженной цене нового тарифа, то для отмены потребуется доплата до стоимости текущего тарифа.

В этом случае система покажет сумму доплаты и предложит оплатить её, чтобы сохранить текущий тариф.

## Важные ограничения

- Если у вас активен **годовой** период, переключение на **месячный** период во время действия подписки не поддерживается.
- Если запланирован даунгрейд, выбор другого тарифа будет недоступен до отмены запланированного изменения.

---

Источник: https://statuser.cloud/docs/billing-change-plan


# Способы оплаты

Карта, СБП, оплата по счёту, автоплатёж и уведомления об оплате

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

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

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

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

---

В Statuser поддерживаются три способа оплаты: **банковская карта**, **СБП** и **оплата по счёту**.
Все способы оплаты доступны в панели управления в разделе [Тарифы и оплата](https://statuser.cloud/my/account/billing).

В форме доступен выбор тарифа, периода оплаты (месяц или год, при оплате за год действует скидка 20%) и способа оплаты.

## Банковская карта

1. В поле **Способ оплаты** выберите **Карта**.
2. (Опционально) включите чекбокс **Сохранить карту для автоматических платежей** — это включит автопродление.
3. Нажмите **Оплатить / Продлить** — вы будете перенаправлены на страницу оплаты банка.
4. После завершения оплаты вы вернётесь в Statuser, а статус отобразится в разделе **Платежи по карте**.

После успешной оплаты:

- тариф активируется/продлевается;
- **чек** будет доступен в деталях платежа и придёт на емейл.

## СБП

1. В поле **Способ оплаты** выберите **СБП**.
2. (Опционально) включите чекбокс **Сохранить счёт для автоматических платежей** — счёт будет привязан по правилам СБП и сможет использоваться для автопродления.
3. Нажмите **Оплатить / Продлить** — откроется окно **с QR‑кодом**.
4. Отсканируйте QR‑код в приложении банка (или камерой) и подтвердите оплату.

После оплаты статус обновится автоматически:

- при успехе тариф обновится, а чек будет доступен в истории платежей;
- при ошибке вы увидите сообщение и сможете создать платёж заново или выбрать другой способ.

> **Важно**
> Если вы не успели оплатить, QR‑код может перестать действовать — просто
> создайте новый платёж.

## Оплата по счёту

Этот способ удобен для юридических лиц и оплаты по реквизитам.

1. В поле **Способ оплаты** выберите **Счёт**.
2. Заполните данные плательщика (или выберите уже сохранённого).
3. Нажмите **Выставить счёт**.

После этого Statuser сформирует счёт в PDF:

- его можно скачать и открыть в новой вкладке;
- копия счёта отправляется на емейл плательщика, если он указан.

Тариф активируется автоматически **после поступления средств** — срок зависит от банка и может занимать от нескольких часов до нескольких рабочих дней.

> Подробнее про документы и особенности оплаты по счёту — в статье [Оплата по счёту для юридических лиц](/docs/billing-invoices).

## Автоплатёж (автопродление)

Автоплатёж доступен, если при оплате вы включили **сохранение карты** или **сохранение счёта СБП**.

- списание выполняется **за 3 дня до окончания** текущего тарифа;
- если оплата не прошла, Statuser сделает ещё попытки (за 2 и за 1 день до окончания);
- если все попытки неудачны, потребуется **оплатить вручную**.

Дополнительно за 4 дня до истечения тарифа отправляется напоминание об автоплатеже.

В любой момент можно отключить автопродление: в разделе **Тарифы и оплата** нажмите **Отвязать** у привязанной карты/счёта.

> Если карта или счёт **не привязаны**, автоплатёж не выполняется. В этом случае
> Statuser отправляет напоминания о продлении тарифа (если у вас включены
> уведомления в аккаунте) за **7, 3 и 1 день** до окончания тарифа.

---

Источник: https://statuser.cloud/docs/billing-payment-methods


# Оплата по счёту для юридических лиц

Как проходит оплата и какие документы формируются после

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

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

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

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

---

Statuser работает по договору-оферте. Оплату принимает **ИП на режиме НПД** (налог на профессиональный доход).

Это означает, что подтверждающим документом об оплате является **чек**, сформированный через сервис ФНС (nalog.ru / приложение «Мой налог»).

## Особенности работы с НПД

Режим НПД (налог на профессиональный доход) имеет несколько важных особенностей, которые могут быть непривычны, если вы ранее работали с ООО или ИП на общей системе налогообложения:

* основным подтверждающим документом является **чек ФНС**, а не счёт-фактура или УПД
* **НДС не начисляется** и не выделяется в документах
* электронный документооборот (ЭДО) в классическом виде не используется

Все расчёты в Statuser полностью соответствуют требованиям ФНС для режима НПД.

## Как происходит оплата по счёту

Ниже — стандартный сценарий работы со счётом и документами:

1. В панели управления вы формируете **счёт** на выбранный тариф и период
2. Производите оплату удобным способом
3. После поступления оплаты:

    * платёж фиксируется в системе
    * формируется **чек ФНС** через сервис «Мой налог»
    * становятся доступны закрывающие документы

4. Документы автоматически:

    * появляются в панели управления
    * отправляются на емейл

Никаких дополнительных действий с вашей стороны не требуется.

## Какие документы вы получаете

После успешной оплаты доступны следующие документы:

* **Чек ФНС (nalog.ru)** — основной юридически значимый документ, подтверждающий оплату по режиму НПД
* **Счёт** — используется для согласования и проведения оплаты внутри компании
* **Акт выполненных работ** — подтверждает факт оказания услуг за оплаченный период

> На режиме НПД не выставляется НДС и не формируется счёт-фактура.

## Где скачать документы

Скачать документы можно **после оплаты** в панели управления:

1. Откройте **Панель управления → Тарифы и оплаты → Выставленные счета**
2. Выберите нужный счёт со статусом **Оплачен**
3. Скачайте **чек**, **счёт** и **акт**

Документы становятся доступны после фактического поступления средств.
Срок зависит от способа оплаты и банковской обработки и может составлять от нескольких часов до 3–4 рабочих дней.

## Что приходит на емейл

После оплаты документы также отправляются на почту:

* чек ФНС (nalog.ru)
* счёт
* акт

Письма приходят на емейл аккаунта и дублируются на почту, указанную в плательщике.

---

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


# Оплата не выполнена

Уведомления, ограничения после окончания тарифа и как восстановить сервис

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

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

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

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

---

Иногда оплата не проходит с первого раза: банк отклонил операцию, не хватило времени на оплату, не сработал автоплатёж или вы просто забыли продлить тариф.

Ниже — что происходит в Statuser, какие уведомления приходят и как быстро восстановить работу.

## До окончания тарифа

Если карта или счёт **не привязаны**, Statuser отправляет напоминания о продлении тарифа за **7, 3 и 1 день**.

Если включено автопродление (привязана карта или счёт СБП), то сценарий другой:

- за **4 дня** приходит уведомление «завтра будет автоплатёж»
- автосписание выполняется за **3 дня до окончания** тарифа
- если не получилось — будут попытки за **2** и за **1 день** до окончания

## После окончания тарифа

После окончания оплаченного периода аккаунт автоматически переводится на **Free**. Мониторинг продолжит работать, но применятся ограничения бесплатного плана.

Обычно в этот момент:

- если активных серверов больше лимита Free — **лишние серверы ставятся на паузу** (как правило, самые новые)
- отключится мониторинг DNS (сервера DNS будут поставлены на паузу)
- проверки выполняются только из доступных для Free локаций и с минимальным интервалом тарифа
- отключается мониторинг SSL/домена, а также часть диагностических возможностей
- если опубликованных статус‑страниц больше лимита — лишние будут сняты с публикации, а кастомный домен и white‑label отключатся
- доступная история инцидентов сократится до 7 дней

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

1. Перейдите в **ПУ → Тарифы и оплата**.
2. Выберите тариф и период (месяц или год).
3. Оплатите любым удобным способом: **карта**, **СБП** или **счёт**.

После успешной оплаты тариф активируется автоматически:

- при оплате картой/СБП — обычно сразу после подтверждения банком
- при оплате по счёту — после поступления средств

Если хотите избежать повторения ситуации, включите автопродление: при оплате отметьте «Сохранить карту/счёт для автоматических платежей», а при необходимости отвязать карту или можно будет в любой момент в разделе **Тарифы и оплата**.

---

Источник: https://statuser.cloud/docs/billing-failed-payment


# Управление API ключами

Создание, использование и безопасность API ключей для интеграций с вашим аккаунтом

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

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

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

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Доступ к публичному API | да | да | да |

Публичный API и MCP-сервер доступны на всех тарифах, включая Free. Но методы, которые управляют платными функциями, вернут ошибку, если функция недоступна на вашем тарифе.

Сравнение тарифов: 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

---

API-ключи позволяют выполнять авторизованные запросы к API от имени вашей учётной записи. Используйте их для интеграции со сторонними системами, автоматизации мониторинга и управления настройками.

## Возможности

- Доступ ко всем разрешённым методам API
- Настраиваемый срок действия (по умолчанию — бессрочный)
- Возможность создать несколько ключей под разные задачи

## Безопасность

> Ключ отображается **только один раз** — сразу после создания. Сохраните его заранее. При утере ключа — удалите его и создайте новый.

- Ключи можно в любой момент отозвать
- Не передавайте ключи в открытом виде
- Храните ключи в безопасном хранилище (например, в переменных окружения или Secrets Manager)

## Рекомендации

- Создавайте отдельные ключи для разных систем и команд
- Устанавливайте срок действия для временных интеграций
- Регулярно проверяйте список активных ключей и удаляйте неиспользуемые

## Пример использования

При обращении к API необходимо передавать ключ в заголовке:

```text
Authorization: Bearer <your_api_key>
```

> Полный список методов и параметров — [в документации API](/api-reference).

---

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