Tijdens een deploy kan een site een minuut lang fouten geven. Start een onderhoudsvenster vanuit je pipeline: de monitors erin worden niet gecontroleerd, er worden geen incidenten geopend, er gaan geen meldingen uit en de tijd telt niet mee voor de uptime. Beëindig het venster als de deploy klaar is, en de checks gaan meteen weer verder.
Voordat je begint
De REST API zit in Professional en Business. Maak een API-sleutel aan met Read & write onder Settings › API, en sla hem op als secret in je CI, hier UPTIMECHECK_API_KEY.Zoek de ID’s op van de monitors die je wilt pauzeren. Elke ID begint met mon_ en is het laatste deel van het adres van de monitorpagina; je kunt ze ook allemaal opvragen:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H “Authorization: Bearer $UPTIMECHECK_API_KEY” | jq -r ‘.data[] | [.id, .name] | @tsv’
GitHub Actions
Deze workflow start een venster van 30 minuten, voert de deploy uit en beëindigt het venster, of de deploy nu gelukt is of niet. Vervang de monitor-ID’s en de deploystap door die van jezelf. In elke andere CI werken dezelfde twee calls.
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”
Is Uptimecheck niet bereikbaar, dan draait de deploy gewoon, zonder venster.
De twee calls
POST /api/v1/maintenance start of plant een venster. Stuur title, startsAt en endsAt als ISO 8601-tijden zoals 2026-10-18T14:00:00Z, en monitorIds. Een starttijd in het verleden start het venster nu, en een venster duurt maximaal 14 dagen. De data.id in het antwoord begint met mw_.Optionele velden: message, dat op statuspagina’s verschijnt, en notifySubscribers (false, tenzij je true stuurt), waarmee abonnees van de statuspagina een e-mail krijgen.DELETE /api/v1/maintenance/{id} beëindigt een lopend venster direct, of annuleert een venster dat nog niet begonnen is. Het antwoord is 204.
Goed om te weten
Zet endsAt iets na je traagste deploy. Stopt de job voor de laatste stap, dan eindigt het venster toch op tijd.Statuspagina’s die deze monitors tonen, melden tijdens het venster Maintenance in progress en vermelden het met de titel, net als de statuswidget. Kies dus een titel die bezoekers mogen zien.Een incident dat openstaat wanneer het venster begint, wordt gesloten, en de monitor begint opnieuw met een verse check wanneer het venster eindigt.Cronjob-pings die tijdens het venster binnenkomen, worden genoteerd maar veranderen niets, en een gemiste ping tijdens het venster geeft geen melding.Met de API kun je ook losse monitors pauzeren en hervatten (POST /api/v1/monitors/{id}/pause en /resume). Voor een deploy is een venster eenvoudiger, omdat het vanzelf eindigt.
Alle velden staan in de API-referentie. Wil je vensters liever in de app plannen, zie dan een onderhoudsvenster plannen. Meer over de REST API.