Начать
Документация

HTTP-чеки

В отличие от heartbeat-чеков, где пингует ваша задача, HTTP-чек опрашивает URL сам — сервис делает запрос с заданным интервалом и алертит, когда ответ перестаёт устраивать.

Параметры

Чек создаётся в дашборде (тип «HTTP») или через API — поле http_config:

Параметр По умолчанию Описание
url—http/https, до 2048 символов
methodGETGET / HEAD / POST
timeout_sec101–30 сек на весь запрос
expected_codes2xx, 3xxдо 10 значений: классы («2xx») и/или конкретные коды (301)
keyword—строка, которая должна присутствовать в теле ответа
keyword_absentfalsetrue — строка, наоборот, должна отсутствовать
follow_redirectstrueследовать ли за редиректами
headers—до 10 кастомных заголовков
basic_auth—username + password
ssl_days_before147 / 14 / 30 — за сколько дней до истечения сертификата алертить
confirmations2K подряд неуспешных проверок до статуса down (1–5)

Расписание HTTP-чека — всегда фиксированный интервал (30–3600 сек); cron-выражения — только для heartbeat-чеков. Запросы уходят с User-Agent: CronAlive-Probe/1.0. Для метода HEAD keyword-проверка неприменима — тело пустое.

Минимальный интервал по тарифам

Free Pro Business
5 мин1 мин30 сек

Что считается провалом

Каждая проверка фиксируется: код ответа, латентность (мс), регион пробы, текст ошибки. Латентность видна на графике длительности на странице чека.

Как правильно проверять сайт

Параметры выше — это три слоя проверки; каждый ловит свой класс проблем, и полезно понимать, что именно закрывает каждый слой:

Лучшая практика: endpoint /health

Надёжнее всего проверять не главную страницу, а отдельный endpoint /health, который сам трогает критичные зависимости (БД, кэш) и отвечает 200 с телом healthy только когда всё живо. Чек для него: ожидаемый код 200 + строка healthy — все три слоя работают на полную. 

# параметры чека
url:            https://example.com/health
expected_codes: 200
keyword:        healthy

Пример /health на PHP:

<?php // public/health.php
try {
    $db = new PDO('pgsql:host=127.0.0.1;dbname=app', 'app', getenv('DB_PASSWORD'));
    $db->query('SELECT 1');               // БД отвечает
    (new Redis())->connect('127.0.0.1');  // кэш отвечает
    echo 'healthy';
} catch (Throwable) {
    http_response_code(500);
    echo 'unhealthy';
}

И то же на Python (Flask):

@app.get("/health")
def health():
    try:
        db.session.execute(text("SELECT 1"))  # БД отвечает
        cache.get("health-probe")             # кэш отвечает
    except Exception:
        return "unhealthy", 500
    return "healthy", 200

Как часто и откуда мы проверяем

Основные проверки выполняет сервер DE (основной сервер мониторинга, Германия) — строго с интервалом чека. Дополнительно работают внешние пробы RU и US: они подключаются для подтверждения падений и периодически опрашивают здоровые чеки (baseline, см. ниже). В логах вашего сервера запросы видны с User-Agent: CronAlive-Probe/1.0: из DE — каждый интервал чека, из RU и US — примерно раз в 15 минут плюс во время инцидентов.

K-подтверждений и кворум регионов

Один неудачный запрос — ещё не инцидент. Статус down присваивается только после confirmations (по умолчанию 2) подряд неуспешных проверок — падение детектится максимум за K интервалов. Первый же успешный ответ сбрасывает счётчик и возвращает чек в up.

Дополнительно down требует кворума из двух регионов: после K провалов DE задание немедленно рассылается пробам RU и US, и флип происходит, только когда провал видят минимум два разных региона в 15-минутном окне. Локальная сетевая проблема одного региона ложный алерт не вызывает.

Baseline-опросы и «хронические» регионы (гео-блоки)

Чтобы у каждого региона была история, внешние пробы опрашивают и здоровые чеки — примерно раз в 15 минут (это и есть baseline-опрос; именно поэтому владелец URL видит редкие запросы CronAlive-Probe/1.0 из RU/US и постоянные из DE).

Если сайт заблокирован для какого-то региона (типовой кейс — гео-блок российских IP), этот регион стабильно фейлит проверки при живых остальных. Такой регион считается «хроническим»: его провалы не подтверждают down, ложных алертов от гео-блока не будет, а статус чека остаётся up. На странице чека в блоке «Доступность по регионам» такой регион помечен бейджем «Недоступен из RU» с пояснением — там же виден последний результат каждого региона (обновляется живьём, без перезагрузки).

TLS-бейдж и SSL-алерты

Для https-адресов сервис следит за сроком сертификата: проверка — раз в 12 часов, с основного сервера (DE), при успешной основной проверке. Результат виден бейджем «TLS: N дн.» на странице чека и в списке: зелёный — до истечения больше порога, жёлтый — меньше порога (порог = ssl_days_before чека или 14 дней), красный — истёк, серый «н/д» — сертификат получить не удалось.

Алерт — отдельно и по желанию: когда до истечения остаётся ≤ ssl_days_before дней, во все включённые интеграции проекта уходит уведомление (в webhook — событие ssl_expiring). Чтобы отключить алерт, оставьте поле «SSL» пустым — бейдж при этом продолжит показывать срок.

Поведение