Et deploy kan få et website til at svare med fejl i et minut. Start et vedligeholdelsesvindue fra din pipeline, så bliver dets monitorer ikke tjekket, ingen hændelser åbnes, ingen alarmer sendes, og tiden tæller ikke med i oppetiden. Afslut vinduet, når deployet er færdigt, så genoptages tjekkene med det samme.
Før du starter
REST API’et er inkluderet i Professional og Business. Opret en API-nøgle med Read & write under Settings › API, og gem den som en secret i dit CI, her UPTIMECHECK_API_KEY.Find id’erne på de monitorer, der skal sættes på pause. Hvert id starter med mon_ og er den sidste del af monitorsidens adresse, eller du kan liste dem alle:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H “Authorization: Bearer $UPTIMECHECK_API_KEY” | jq -r ‘.data[] | [.id, .name] | @tsv’
GitHub Actions
Dette workflow starter et vindue på 30 minutter, deployer og afslutter vinduet, uanset om deployet lykkedes eller ej. Erstat monitor-id’erne og deploy-trinnet med dine egne. I ethvert andet CI virker de samme to kald.
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
env:
UPTIMECHECK_API_KEY: ${{ secrets.UPTIMECHECK_API_KEY }}
steps:
– uses: actions/checkout@v4
– name: Start maintenance
id: maintenance
run: |
body=$(jq -n \
–arg start “$(date -u +%Y-%m-%dT%H:%M:%SZ)” \
–arg end “$(date -u -d “+30 minutes” +%Y-%m-%dT%H:%M:%SZ)” \
‘{title: “Deploying a new version”, startsAt: $start, endsAt: $end,
monitorIds: [“mon_9xk2m1q8w4”, “mon_4t7p2k8d1z”]}’)
id=$(curl -sS -X POST https://app.uptimecheck.com/api/v1/maintenance \
-H “Authorization: Bearer $UPTIMECHECK_API_KEY” \
-H “Content-Type: application/json” \
-d “$body” | jq -r ‘.data.id // empty’)
echo “id=$id” >> “$GITHUB_OUTPUT”
– name: Deploy
run: ./deploy.sh
– name: End maintenance
if: always() && steps.maintenance.outputs.id != ”
run: |
curl -sS -X DELETE \
“https://app.uptimecheck.com/api/v1/maintenance/${{ steps.maintenance.outputs.id }}” \
-H “Authorization: Bearer $UPTIMECHECK_API_KEY”
Kan Uptimecheck ikke nås, kører deployet alligevel, bare uden et vindue.
De to kald
POST /api/v1/maintenance starter eller planlægger et vindue. Send title, startsAt og endsAt som ISO 8601-tidspunkter, for eksempel 2026-10-18T14:00:00Z, og monitorIds. En start i fortiden starter det nu, og et vindue varer højst 14 dage. Svarets data.id starter med mw_.Valgfrie felter: message, der vises på statussider, og notifySubscribers (false, medmindre du sender true), der sender en e-mail til statussidens abonnenter.DELETE /api/v1/maintenance/{id} afslutter et igangværende vindue med det samme eller annullerer et, der ikke er startet. Det svarer 204.
Godt at vide
Sæt endsAt lidt efter dit langsomste deploy. Hvis jobbet dør før det sidste trin, slutter vinduet alligevel til tiden.Statussider, der viser disse monitorer, skriver Maintenance in progress under vinduet og viser det med dets titel, og det samme gør status-widgetten. Vælg en titel, som besøgende gerne må se.En hændelse, der er åben, når vinduet starter, lukkes, og monitoren begynder forfra med et nyt tjek, når vinduet slutter.Pings fra cron-jobs, der kommer under vinduet, registreres, men ændrer ingenting, og et ping, der mangler i den periode, udløser ingen alarm.API’et kan også sætte enkelte monitorer på pause og genoptage dem (POST /api/v1/monitors/{id}/pause og /resume). Et vindue er enklere til et deploy, da det slutter af sig selv.
Alle felter står i API-referencen. Vil du hellere planlægge vinduer i appen, så se sådan planlægger du et vedligeholdelsesvindue. Læs mere om REST API’et.