CI/CD, запланированное обслуживание и API статуса StillOnline
Зелёный пайплайн не отменяет вопросов клиентов «у вас лежит?», когда пробы на секунды краснеют. Запланированное обслуживание на публичной странице статуса задаёт ожидания; CI может открыть пост, чтобы не забыть ночью.
На Pro REST позволяет создавать инциденты (в том числе текст обслуживания). Закрытие и часть правок в API v1 — в интерфейсе. Внешние HTTP-проверки идут дальше, пока вы не меняете health URL. Продумайте текст для клиентов и алерты в Telegram для себя.
Краткий ответ
Перед рискованным деплоем откройте инцидент scheduled maintenance на странице статуса StillOnline (UI или Pro POST …/incidents). Проба может стать жёлтой/красной — напишите это в теле инцидента. Из CI вызывайте REST API с sk_live_… в secrets, не в репозитории. Resolved — в приложении, когда проверки зелёные. Неожиданный простой по-прежнему будит владельца через бота StillOnline.
Что автоматизировать, что оставить в UI
| Шаг | CI (Pro API) | Пока только UI (v1) |
|---|---|---|
| Открыть инцидент обслуживания | POST /status-pages/{id}/incidents | Редактура формулировок |
active_incident в публичном JSON | После создания | — |
| Закрыть / resolve | — | Resolve в панели |
| «Пауза» пробы | Отдельного API нет | Смена health URL или краткий red |
Эндпоинты: /ru/docs/api · REST.
Паттерн пайплайна (GitHub Actions, GitLab и др.)
- Pre-deploy — инцидент: заголовок Scheduled maintenance, окно UTC и что затронуто.
- Deploy — ваши шаги.
- Post-deploy —
curlпубличного JSON или private checks;operational. - Follow-up — resolve в StillOnline, когда зелёный.
Публичное чтение (без ключа):
curl -sS "https://api.stillonline.tech/v1/public/status/my-saas" | jq '.status,.active_incident'
Private checks (secret STILLONLINE_API_KEY):
curl -sS -H "Authorization: Bearer $STILLONLINE_API_KEY" \
"https://api.stillonline.tech/v1/projects/$PROJECT_ID/checks"
sk_live_… только в secrets CI. Не коммитьте и не вставляйте в промпты LLM.
Текст инцидента: шаблон поста. Вручную: запланированное обслуживание.
Если пробы алертят во время работ
StillOnline сравнивает health URL с ожидаемым кодом каждый интервал. Честный 503 при миграции — красный на странице.
- В инциденте: «Проверки могут быть degraded во время миграции».
- Алерты владельца оставьте включёнными на случай затянувшегося простоя.
- Не вешайте production-проверку на staging.
На Free — обслуживание только в UI. Pro, когда CI должен создавать инциденты.
Связанные материалы
- Запланированное обслуживание на странице статуса
- REST API uptime и статуса
- GitHub Actions и API StillOnline
- Алерты в Telegram
FAQ
Может ли CI закрыть инцидент обслуживания в StillOnline автоматически?
В API v1 создание через REST на Pro есть; закрытие — только UI (REST). Заложите шаг в панели или напоминание on-call после деплоя.
Сработают ли алерты Telegram во время scheduled maintenance?
При non-200 на health URL алерты владельца могут прийти. Это полезно, если деплой затянулся. Опишите план в инциденте; при шуме настройте health-маршрут.
Есть ли в StillOnline «режим обслуживания» с паузой проб?
Отдельной паузы для клиентов в доках нет. Примите состояние проб или временно отдайте /health с контролируемым 200. См. дизайн health endpoint.
API инцидентов на Free?
Нет. Pro / Ultimate и sk_live_… в настройках API. На Free — пост в веб-интерфейсе.
Что проверять в CI после деплоя?
GET /public/status/{slug} → operational или private checks → last_status. REST.
Чем это отличается от uptime-проверок в GitHub Actions?
Здесь — коммуникация с клиентом (страница статуса + инциденты). Гейты по пробам: GitHub Actions и API.