CI/CD, scheduled maintenance, and the StillOnline status API

A green deploy pipeline does not stop customers from asking “is it down?” when probes briefly fail. Scheduled maintenance on your public status page sets expectations; CI can open that post so you do not forget at 2 a.m.

StillOnline Pro exposes REST endpoints to create incidents (including maintenance copy). Closing and some edits stay in the UI in API v1. External HTTP checks keep running unless you change the health URL. Plan both the customer message and owner Telegram alerts.

Quick answer

Before a risky deploy, open a scheduled maintenance incident on your StillOnline status page (UI or Pro POST …/incidents). Probes may still go yellow or red; say that in the incident body. From CI, call the REST API with sk_live_… in secrets, not in the repo. Mark Resolved in the app when checks are green. Owner down alerts still fire on unexpected failures via the StillOnline bot.

What to automate vs keep manual

Full endpoint list: /en/docs/api · REST guide.

Pipeline pattern (GitHub Actions, GitLab, etc.)

1. Pre-deploy job — create incident: title Scheduled maintenance, body with window UTC and what is affected.
2. Deploy job — your existing steps.
3. Post-deploy — curl public status JSON or private checks API; confirm operational.
4. Human or scheduled follow-up — resolve incident in StillOnline when green.

Example public read (no secret):

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"

Store sk_live_… in CI secrets. Never commit keys or paste them into LLM prompts.

Copy for the incident body: incident post template. Manual-first workflow: scheduled maintenance guide.

When probes alert during planned work

StillOnline compares your health URL to the expected status code on every interval. A real 503 during migration is honest red on the page.

• Write in the incident: “Checks may show degraded while we migrate.”
• Keep owner alerts on so a longer outage than planned pages you.
• Do not point production checks at staging URLs.

On Free, open maintenance in the UI only (no API key). Upgrade to Pro when CI should post incidents.

Related guides

• Scheduled maintenance on your status page
• REST API for uptime and status
• GitHub Actions and the StillOnline API
• Telegram owner alerts

FAQ

Can StillOnline CI jobs close maintenance incidents automatically?

In API v1, creating incidents via REST is supported on Pro; closing is UI-only (REST guide). Plan a dashboard step or an on-call reminder to mark Resolved after deploy.

Will StillOnline Telegram alerts fire during scheduled maintenance?

If the health URL returns non-200, owner alerts can still fire. That is useful when deploy overruns. Explain planned work in the incident post; tune the health route if brief red is unacceptable noise.

Does StillOnline have a “maintenance mode” that pauses probes?

There is no separate pause switch documented for customers. Either accept probe state during work, or temporarily route /health to a controlled 200 maintenance response you own. See health endpoint design.

Is the StillOnline incident API on Free?

No. Pro or Ultimate plus sk_live_… from API settings. Free teams post maintenance in the web UI.

What should CI verify after deploy on StillOnline?

Poll GET /public/status/{slug} for operational, or private GET /projects/{id}/checks for last_status. Match the URL customers use. REST guide.

How is this different from GitHub Actions uptime checks?

This article is about customer comms (status page + incidents). For workflow gates on probe results, see GitHub Actions uptime check API.