Проверки uptime, редиректы и antibot: почему StillOnline зелёный, а войти нельзя

Внешний мониторинг видит только ответ HTTP-клиента на вставленный URL. 302 на страницу входа, длинная цепочка редиректов или 200 от страницы challenge могут выглядеть как «всё работает», пока платящие пользователи застряли.

StillOnline бьёт по health URL по расписанию и фиксирует код HTTP-ответа (и время) на финальном ответе. Ниже — как избежать ложного зелёного без обещаний, которых нет в продукте (нет режима «решить CAPTCHA», на Free нет кастомных заголовков проб).

Краткий ответ

Укажите в StillOnline один канонический HTTPS health URL с 200 и коротким телом, когда продукт жив — обычно GET /api/health на API-хосте, а не маркетинг за antibot. Сначала уберите петли редиректов и авторизацию на health. Не используйте главную, если Cloudflare или Vercel отдаёт 200 ботам. Проверьте curl -L извне, зарегистрируйте URL в StillOnline и подождите 2–3 цикла проверки, прежде чем верить зелёному.

Что делает проба

Воркеры StillOnline по расписанию шлют GET (или выбранный метод) на URL из проверки. На Free в основном сравнивается код ответа с ожидаемым (часто 200). Это не браузер: без JavaScript, без challenge, без входа в приложение.

Подробнее про маршруты: дизайн health endpoint.

Редиректы: типичные ошибки

Для браузера редиректы нормальны; монитору нужен стабильный финальный URL.

1. HTTP → HTTPS — ок, если один переход и 200.
2. www и apex — один канонический хост для проверки.
3. Региональные/языковые редиректы — могут увести пробу не туда.
4. Редирект на «заглушку» при сбое — не вешайте проверку на блог вместо API.

Проверка «как проба»:

curl -sS -o /dev/null -w "%{http_code} final:%{url_effective}\n" -L --max-redirs 5 "https://api.yourproduct.com/health"

Нужны 200 и разумный final:. Много переходов — чините маршрутизацию.

Платформы: Vercel · Cloudflare Workers.

Antibot, WAF и challenge

Режимы Cloudflare, bot management и шаблоны WAF иногда отдают 200 с HTML challenge не-браузерам — или 403 пробам.

Что делать:

• Отдельный health на API-поддомене с мягче правилами (разрешить user-agent мониторов, если провайдер умеет).
• Не использовать только лендинг за жёсткой защитой.
• На Pro — вторая проверка: «маркетинг» и «API» раздельно.

StillOnline в v1 не обходит CAPTCHA и не выполняет JS challenge. Если единственный публичный URL за интерактивной защитой — меняйте инфраструктуру.

StillOnline после исправления URL

1. Быстрый старт health URL.
2. Старт бесплатно → проверка → GET → 200.
3. 2–3 интервала (5 мин на Free) перед «зелёным».
4. Алерты в Telegram — человек хотя бы раз глянет тело ответа.

Для скриптов: публичный JSON статуса.

Связанные материалы

• Health URL — быстрый старт
• Health endpoint: /health и /ready
• API-only SaaS: что мониторить
• Чеклист мониторинга side project

FAQ

Почему StillOnline operational, а в браузере challenge Cloudflare?

Проба получила ожидаемый код (часто 200) на зарегистрированном URL — challenge иногда отдаёт 200 не-браузерам. Укажите API health с правилами WAF для внешних GET. CAPTCHA StillOnline в v1 не решает.

StillOnline следует редиректам на health?

Как обычный HTTP-клиент, с разумным лимитом; длинные и циклические цепочки дают флап. Лучше один канонический HTTPS с прямым 200 — дизайн health endpoint.

Можно ли слать кастомные заголовки, чтобы обойти antibot?

Не как документированная функция на Free — настройте edge так, чтобы /health принимал внешние GET без секретов. API-ключи в health URL не кладите.

Проверка красная, в Chrome всё ок — что делать?

В Chrome есть JS и cookies; у пробы нет. Сравните код и финальный URL через curl -L. Исправьте auth на health, редиректы или WAF — обновите URL проверки в StillOnline в том же PR.

Алерты в Telegram, если после деплоя сломались редиректы?

Да — с алертами владельца в Telegram неуспешная проба дойдёт до телефона, даже если лендинг открывается. Меняйте URL проверки при смене домена или пути.