Публічна сторінка статусу показує поточну доступність ядра платформи Zentor App. Вона напряму й без кешування запитує кінцеву точку перевірки стану бекенду. Відображається, чи доступні бекенд і база даних на момент запиту. Сторінка свідомо не містить вигаданого відсотка аптайму та жодної історичної оцінки SLA.
Позитивний статус не означає, що кожна окрема функція тенанта працює без помилок. Доступ WhatsApp може бути неправильно налаштований, пароль SMTP — застарілий, а домен — не дозволений, навіть якщо ядро платформи доступне. Зовнішні постачальники, як-от Twilio, PayPal або ШІ-провайдер, загальна перевірка стану автоматично повністю не охоплює.
У разі збою спершу слід відкрити сторінку статусу. Якщо вона повідомляє про критичну помилку, повторні локальні зміни конфігурації зазвичай не мають сенсу. Якщо платформа доступна, далі йде діагностика тенанта: панель стану системи, кнопки тестування каналів і логи. Логи містять щонайбільше 500 рядків і не мають фільтра. У вкладці Automation-Runs немає кнопки повторної спроби.
Відображене — це знімок стану на момент перегляду. Для нової перевірки сторінку потрібно оновити. Вона не може довести, що раніше збою не було. Для звернення до підтримки слід записати час, тенанта, порушену функцію, видиму помилку та відтворювані кроки. Секрети та персональні тексти повідомлень не слід без запиту додавати до звернення.
Отже, сторінка статусу відповідає лише на запитання, чи доступна центральна платформа зараз. Вона не замінює ні тестів окремих каналів, ні перевірки ізольованого екземпляра SIP. Публічна історична статистика доступності чи публічний SLA наразі не надаються.
Якщо сторінка взагалі не завантажується в браузері, слід додатково перевірити власне інтернет-з'єднання або розв'язання DNS. Локальна проблема мережі може створити таке саме враження, як і збій платформи. І навпаки, доступна кінцева точка статусу не є доказом працездатності окремого фронтенд-бандла. Тому до розширеної діагностики належать консоль браузера та мережевий протокол.
У разі повторюваних збоїв доцільно вести часовий ряд власних спостережень, оскільки сама публічна сторінка історії не зберігає. Час, тривалість і порушені функції можна документувати всередині компанії. Проте з цього не можна виводити офіційний показник доступності Zentor, доки відповідну статистику платформи не опубліковано.
Крім того, слід перевірити, чи стосується проблема лише однієї мовної версії, окремого пристрою чи всіх користувачів. Таке звуження допомагає розмежувати причини у фронтенді, мережі та бекенді й запобігає непотрібним змінам у конфігурації тенанта, що працює справно.