Während eines Deployments kann eine Website für eine Minute Fehler liefern. Starten Sie aus Ihrer Pipeline ein Wartungsfenster: Dann werden die betroffenen Monitore nicht geprüft, es werden keine Vorfälle eröffnet und keine Alarme verschickt, und die Zeit zählt nicht gegen die Uptime. Beenden Sie das Fenster nach dem Deployment, und die Checks laufen sofort weiter.
Bevor Sie beginnen
Die REST API ist in Professional und Business enthalten. Erstellen Sie einen API-Schlüssel mit Read & write unter Settings › API und hinterlegen Sie ihn als Secret in Ihrer CI, hier als UPTIMECHECK_API_KEY.Ermitteln Sie die IDs der Monitore, die pausiert werden sollen. Jede beginnt mit mon_ und ist der letzte Teil der Adresse der Monitorseite. Oder lassen Sie sich alle auflisten:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H „Authorization: Bearer $UPTIMECHECK_API_KEY“ | jq -r ‚.data[] | [.id, .name] | @tsv‘
GitHub Actions
Dieser Workflow startet ein 30-minütiges Fenster, deployt und beendet das Fenster wieder – egal, ob das Deployment geklappt hat oder nicht. Ersetzen Sie die Monitor-IDs und den Deploy-Schritt durch Ihre eigenen. In jeder anderen CI funktionieren dieselben zwei Aufrufe.
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“
Ist Uptimecheck nicht erreichbar, läuft das Deployment trotzdem – nur ohne Fenster.
Die zwei Aufrufe
POST /api/v1/maintenance startet oder plant ein Fenster. Senden Sie title, startsAt und endsAt als ISO-8601-Zeitangaben wie 2026-10-18T14:00:00Z sowie monitorIds. Liegt der Start in der Vergangenheit, beginnt das Fenster sofort, und ein Fenster dauert höchstens 14 Tage. Die data.id der Antwort beginnt mit mw_.Optionale Felder: message, das auf Statusseiten angezeigt wird, und notifySubscribers (false, sofern Sie nicht true senden), womit die Abonnenten der Statusseite per E-Mail informiert werden.DELETE /api/v1/maintenance/{id} beendet ein laufendes Fenster sofort oder sagt eines ab, das noch nicht begonnen hat. Die Antwort lautet 204.
Gut zu wissen
Setzen Sie endsAt etwas später als Ihr langsamstes Deployment. Bricht der Job vor dem letzten Schritt ab, endet das Fenster trotzdem pünktlich.Statusseiten, die diese Monitore zeigen, melden während des Fensters Maintenance in progress und führen es mit seinem Titel auf, ebenso das Status-Widget. Wählen Sie also einen Titel, den Besucher sehen dürfen.Ein Vorfall, der beim Start des Fensters offen ist, wird geschlossen, und der Monitor beginnt nach dem Fenster mit einem neuen Check von vorn.Cron-Job-Pings, die während des Fensters eintreffen, werden vermerkt, ändern aber nichts, und ein in dieser Zeit ausbleibender Ping löst keinen Alarm aus.Über die API lassen sich auch einzelne Monitore pausieren und fortsetzen (POST /api/v1/monitors/{id}/pause und /resume). Für ein Deployment ist ein Fenster einfacher, da es von selbst endet.
Alle Felder finden Sie in der API-Referenz. Um Fenster stattdessen in der App zu planen, siehe Wartungsfenster planen. Mehr zur REST API.