Прозорість сервісів

Статус-модель для сервісів, що несуть ваші сповіщення

Коли сповіщення залишає ваш моніторинг і доходить до телефону чи Telegram, вісім сервісів мають бути справними. Ця сторінка їх називає, показує стан і пояснює, як WardenPoint комунікує деградацію.

Почати безкоштовно Повідомити інцидент

Усі системи

Працює

Усі системи працюють

Стан у реальному часі з проб для кожного компонента. Деталі та 90-денні стрічки нижче.

Доступність 90д
99.99%
Компоненти
6
Вікно
90d

Компоненти

Стан кожного сервісу на шляху сповіщення

Кожен батьківський елемент має власну 90-денну смугу доступності. Розкрийте рядок, щоб побачити постачальників на нижчому рівні.

Публічний API та приймання

Працює
99.99%90д

Останні 90 днів

Дашборд

Працює
100.00%90д

Останні 90 днів

Доставка сповіщень

Працює
99.99%90д

Останні 90 днів

Телефонія Asterisk

Працює
99.97%90д

Останні 90 днів

База даних

Працює
100.00%90д

Останні 90 днів

Redis і черга

Працює
100.00%90д

Останні 90 днів

Сфера

Що ця сторінка покриває — і чого ні

Частина режимів збою — всередині WardenPoint, і ми звітуємо про них тут. Інші — у провайдерів каналів або вашого джерела моніторингу. Про це говоримо прямо.

Наш прийом, маршрутизація і ескалація

Якщо публічне API перестає приймати alert-и, диспетчер зависає або кроки ескалації не запускаються вчасно — фіксуємо тут як інцидент.

Наші адаптери каналів

Якщо наш диспетчер Telegram, голосу, SMS, WhatsApp чи email не може передати повідомлення upstream-провайдеру — це в нашій сфері.

Збої сторонніх провайдерів

Telegram, SMS-оператори, поштові relay і PSTN мають власні збої. Ми звітуємо про вплив на доставку, але не лагодимо проблему на стороні upstream.

Політика комунікації

Як ми комунікуємо під час інциденту

Alerting-платформа, що мовчить під час збою, — найгірший тип збою. Ось кроки, яких ми дотримуємось.

  1. 1

    Виявлення

    Наші монітори піднімають внутрішній alert, щойно затримка прийому, лаг ескалації чи помилки диспетчера перетинають поріг.

  2. 2

    Публічне підтвердження

    Протягом ~15 хвилин від підтвердження публікуємо інцидент тут — із переліком зачеплених сервісів і тим, що вже знаємо.

  3. 3

    Регулярні оновлення

    Публікуємо оновлення щонайменше кожні 30 хвилин під час активного інциденту, навіть якщо єдина новина — «ще розслідуємо».

  4. 4

    Закриття і подальші дії

    Коли сервіс повертається, позначаємо як працює і за п'ять робочих днів публікуємо короткий post-mortem зі списком дій.

Будьте в курсі

Як отримувати сповіщення про зміни статусу

Різні команди хочуть інцидент-сповіщень у різних місцях. Оберіть шлях, який пасує до вашого чергування.

Email-дайджест

Підпишіться на статусні листи з дашборду акаунту. Отримуєте відкриття, оновлення і закриття інциденту.

Webhook (рекомендовано)

Зареєструйте URL incident-webhook у дашборді. Ми POST-имо JSON при кожній зміні стану — вмонтуйте його у власну маршрутизацію.

Прямий контакт

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

Безкоштовний план

Перевірте доставку власним тестом, перш ніж покладатися на неї

Найшвидший спосіб довіряти цій сторінці — надіслати власний тестовий alert і подивитися стрічку. Без кредитки. Без зобов'язань.

Почати безкоштовно Зв'язатися з підтримкою
  • Безкоштовний план
  • Тестовий alert сьогодні
  • Журнал аудиту для кожного відправлення