GitHub Actions: gate deploys with the StillOnline uptime API

A passing unit test suite does not prove production answers HTTP 200 from the internet. GitHub Actions can call StillOnline’s read-only API after deploy (or before promote) so a red external check blocks the workflow.

You do not need to scrape HTML. Use GET /v1/public/status/{slug} without a key, or GET /v1/projects/{id}/checks with Bearer sk_live_… on Pro. Owner down alerts stay separate: Telegram via StillOnline bot.

Quick answer

After deploy, add a GitHub Actions step that curls StillOnline public status JSON (operational) or, on Pro, private checks with Authorization: Bearer and a repo secret STILLONLINE_API_KEY. Store sk_live_… only in GitHub Secrets. Public endpoint: 60 req/min per IP; private: 120/min per key. Opening maintenance incidents from CI is a different flow: CI/CD maintenance.

Choose public vs private JSON

Base URL: https://api.stillonline.tech/v1. Details: REST service uptime.

Example workflow (public status)

name: Post-deploy smoke
on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  stillonline-status:
    runs-on: ubuntu-latest
    steps:
      - name: Check public status JSON
        run: |
          STATUS=$(curl -sS "https://api.stillonline.tech/v1/public/status/my-saas" | jq -r '.status')
          echo "overall=$STATUS"
          test "$STATUS" = "operational"

Replace my-saas with your status slug. Non-zero exit fails the job.

Example workflow (private checks, Pro)

      - name: Check StillOnline probes (private API)
        env:
          STILLONLINE_API_KEY: ${{ secrets.STILLONLINE_API_KEY }}
          STILLONLINE_PROJECT_ID: ${{ vars.STILLONLINE_PROJECT_ID }}
        run: |
          curl -sS -H "Authorization: Bearer $STILLONLINE_API_KEY" \
            "https://api.stillonline.tech/v1/projects/$STILLONLINE_PROJECT_ID/checks" \
            | jq -e '.checks[] | select(.last_status != "OPERATIONAL")' && exit 1 || exit 0

Adjust jq to your tolerance (e.g. allow DEGRADED). Create the key once at API settings.

Common mistakes

• Checking preview URLs — gate production slug only (probe redirects).
• No health URL yet — API reflects probes; ship /api/health first (quickstart).
• Secrets in workflow logs — GitHub masks secrets.*; never echo the key.
• Confusing status page with app login — API JSON is not your SaaS session.

Pair workflow gates with a public link in README: public status page guide.

Related guides

• REST API for service uptime
• CI/CD maintenance and incidents
• Health check URL quickstart
• MCP in Cursor for checks

FAQ

Does StillOnline offer an official GitHub Action marketplace card?

Use plain curl or jq in a run step against documented REST endpoints (REST guide). No separate marketplace action is required for v1.

Can GitHub Actions create StillOnline checks via API?

Read paths are the usual CI gate. Creating checks may be available via API/MCP on Pro for agents; typical deploy smoke reads status. See MCP post for agent workflows.

What if the job gets HTTP 429 from StillOnline?

Public JSON is limited to 60 requests/minute per IP. Back off or cache; do not poll every second in a tight loop.

Should CI fail on degraded or only down?

Your policy. Public JSON includes degraded and down. Tighten jq if you want strict operational only.

How do StillOnline owner Telegram alerts relate to GitHub Actions?

Alerts notify humans on probe failure. CI gates block merges or deploys. Use both: Actions for automation, Telegram for on-call.