Un deploy può far rispondere un sito con errori per un minuto. Avvia una finestra di manutenzione dalla tua pipeline: i suoi monitor non vengono controllati, non si aprono incidenti, non partono avvisi e quel tempo non pesa sull’uptime. Chiudi la finestra a deploy terminato e i controlli riprendono subito.
Prima di iniziare
La REST API è inclusa in Professional e Business. Crea una chiave API con Read & write in Settings › API e salvala come secret nella tua CI, qui UPTIMECHECK_API_KEY.Trova gli ID dei monitor da mettere in pausa. Ognuno inizia con mon_ ed è l’ultima parte dell’indirizzo della pagina del monitor, oppure elencali tutti:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H “Authorization: Bearer $UPTIMECHECK_API_KEY” | jq -r ‘.data[] | [.id, .name] | @tsv’
GitHub Actions
Questo workflow avvia una finestra di 30 minuti, esegue il deploy e chiude la finestra sia che il deploy sia riuscito sia che no. Sostituisci gli ID dei monitor e il passaggio di deploy con i tuoi. Le stesse due chiamate funzionano in qualsiasi altra CI.
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”
Se Uptimecheck non è raggiungibile, il deploy parte comunque, senza finestra.
Le due chiamate
POST /api/v1/maintenance avvia o pianifica una finestra. Invia title, startsAt ed endsAt come orari ISO 8601, ad esempio 2026-10-18T14:00:00Z, e monitorIds. Un inizio nel passato la avvia subito e una finestra dura al massimo 14 giorni. Il data.id della risposta inizia con mw_.Campi facoltativi: message, mostrato sulle pagine di stato, e notifySubscribers (false se non invii true), che avvisa via email gli iscritti alla pagina di stato.DELETE /api/v1/maintenance/{id} chiude subito una finestra in corso o annulla una che non è ancora iniziata. Risponde 204.
Da sapere
Imposta endsAt un po’ oltre la durata del tuo deploy più lento. Se il job si interrompe prima dell’ultimo passaggio, la finestra si chiude comunque in orario.Le pagine di stato che mostrano questi monitor indicano Maintenance in progress durante la finestra e la elencano con il suo titolo, e lo stesso fa il widget di stato. Scegli un titolo che i visitatori possano vedere.Un incidente ancora aperto quando inizia la finestra viene chiuso e, alla fine della finestra, il monitor riparte con un nuovo controllo.I ping dei cron job che arrivano durante la finestra vengono registrati ma non cambiano nulla, e un ping mancato in quel periodo non genera avvisi.L’API può anche mettere in pausa e riattivare singoli monitor (POST /api/v1/monitors/{id}/pause e /resume). Per un deploy una finestra è più semplice, perché si chiude da sola.
Tutti i campi sono nella documentazione dell’API. Per pianificare le finestre direttamente nell’app, vedi come pianificare una finestra di manutenzione. Scopri di più sulla REST API.