Мониторинг GraphQL API: health check без поломки production-запросов

Q: Мониторить /graphql напрямую в StillOnline?

Только если GET без auth. POST-only /graphql → 405 на GET. Лучше /health — см. гайд API-only.

GraphQL отдаёт HTTP 200, пока массив errors в JSON кричит о сбое — а аптайм зелёный, потому что монитор бил в POST-only маршрут. Мониторинг GraphQL API строится в два слоя: дешёвый GET sidecar для внешних probe и опциональные GraphQL-canary в CI. Вы добавите GET /health на том же хосте, что /graphql, отключите introspection в production и зарегистрируете один HTTPS URL в StillOnline.

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

GraphQL часто возвращает HTTP 200 при ошибках в поле errors. StillOnline шлёт GET и на Free смотрит только код статуса — без POST body и без разбора JSON. Указывайте GET /health или GET /ready, не POST /graphql. В CI — { __typename }; в production-мониторах не используйте introspection __schema. Free: один проект, один URL, интервал пять минут — тарифы.

GraphQL — один запрос, один JSON-ответ. Сервер может ответить 200 OK, когда resolver упал: транспорт жив, бизнес-логика — нет. Внешний монитор бьёт URL из публичного интернета по расписанию без логина; на Free — без кастомных заголовков.

Базовые паттерны — быстрый старт health URL и мониторинг API-only SaaS. Здесь — ловушки GraphQL: ложный зелёный при 200+errors, POST-only endpoint, introspection-probe и когда GET /health достаточно для StillOnline.

1. Сравнение GET /health и сбоев GraphQL gateway

Liveness — процесс принимает HTTP. Readiness — может обслуживать трафик (БД доступна). У GraphQL gateway третий слой: движок жив, а каждый запрос возвращает resolver errors в JSON — невидимо для монитора, который смотрит только код на неправильном URL.

Слой мониторинга	Что доказывает	Куда подходит
GET /health	Процесс жив	StillOnline Free — только код статуса
GET /ready с ping БД	Зависимости в порядке; 503 при сбое	StillOnline, когда DOWN = БД лежит
POST GraphQL + проверка errors	Resolver отработал	CI — не StillOnline
GET ?query={__typename}	GraphQL HTTP без POST	CI, если сбой даёт не-200

Apollo Server v4+ убрал встроенные health checks. GraphQL Yoga даёт GET /health из коробки. Паттерн StillOnline: тот же хост, что GraphQL, публичный GET /health или /ready, ссылка /s/... в доке API.

Цепочка probe: StillOnline GET каждые ~5 мин → балансировщик → GET /ready → 200 или 503 → страница статуса + алерт владельцу после двух неудачных probe подряд.

Делайте: внешний аптайм через StillOnline. Не делайте: считать 200 на /graphql признаком здоровья продукта.

2. Лёгкие probe-запросы и ловушка introspection

Минимальный безопасный запрос — { __typename }. Introspection __schema в production часто отключена — монитор на introspection даёт ложный DOWN.

Поле healthz с ping БД проверяйте в CI POST-canary, не через StillOnline.

StillOnline Free не шлёт заголовок apollo-require-preflight — держите отдельный /health с простым 200.

Плагин Yoga useReadinessCheck: GET /ready → 503, когда проверка падает.

Делайте: { __typename } в staging/CI. Не делайте: introspection в production-мониторах.

Для REST рядом с GraphQL — health check в FastAPI.

3. Auth, rate limit и ложный зелёный на POST-only API

Многие серверы принимают только POST на /graphql и отвечают 405 на GET. StillOnline шлёт GET без body — прямой мониторинг /graphql даёт ложные алерты.

Хуже partial success: 200 с data и errors одновременно. StillOnline Free не парсит $.errors — верните 503 на /ready при сбое зависимостей или добавьте POST-canary в GitHub Actions.

Sidecar (паттерн Apollo):

app.get('/health', (_req, res) => res.status(200).send('Okay!'));
// GraphQL на POST /graphql — StillOnline бьёт GET /health

Исключите /health и /ready из JWT. Не требуйте API-ключ на URL probe — типичные ложные 401 в 3 ночи.

Коды, таймауты, Cache-Control: дизайн health endpoint. /health — доли секунды; /ready — до трёх секунд.

4. Настройка проверок StillOnline

StillOnline — GET probe, страница статуса, алерты владельцу. Без POST body GraphQL; без разбора JSON на Free.

Один URL. Free — обычно production GET /ready или /health.
curl снаружи сети — ожидайте 200, ответ быстрее 2 с.
Регистрация в stillonline.tech/app — полный HTTPS, GET, ожидание 200.
2–3 цикла (~5 мин на Free).
Алерты — один канал на Free; Pro и Ultimate — больше — тарифы.
Ссылка /s/... в доке API.

Делайте: публичный edge URL. Не делайте: POST /graphql в StillOnline.

Честные лимиты: только GET; без кастомных заголовков на Free; только код статуса; две неудачные probe → DOWN. Ошибки в JSON при 200 — зона CI, не замена /health.

5. Runbook: деплой схемы сломал probe

До деплоя: curl /health и /ready извне.
Переименовали healthz — сначала CI, /health для StillOnline не трогайте.
После деплоя — один цикл на странице статуса.
Federation — gateway /ready → 503, если критичный subgraph недоступен.
Зафиксируйте URL в runbook.

Что дальше

StillOnline на GET /ready + опциональный CI для errors. Подключите Telegram или Slack. Ссылку на статус — в футер.

Дашборд StillOnline → вставьте readiness URL → включите канал, который читаете ночью.

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

FAQ

Можно ли мониторить GraphQL через POST?

У конкурентов — да, с проверкой errors. StillOnline — только GET без body. Используйте GET /health на том же хосте.

Мониторить /graphql напрямую в StillOnline?

Только если GET без auth. POST-only /graphql → 405 на GET. Лучше /health — см. гайд API-only.

StillOnline видит errors в JSON GraphQL?

На Free — нет, только код статуса. Проектируйте /ready с 503 при сбое зависимостей. Для errors в body — CI или GraphQL-native монитор.

/health или /ready в StillOnline?

/ready, если падение БД должно будить дежурного; /health — меньше шума при деплоях.

{ __typename } в production?

В CI — да. Introspection __schema в prod-мониторах — нет.

GraphQL + StillOnline Free: staging или production?

Один URL на Free — production. Pro — отдельные проверки для окружений.