Un déploiement peut faire renvoyer des erreurs à un site pendant une minute. Lancez une fenêtre de maintenance depuis votre pipeline : ses moniteurs ne sont plus vérifiés, aucun incident ne s’ouvre, aucune alerte ne part, et ce temps n’est pas décompté de la disponibilité. Refermez la fenêtre une fois le déploiement terminé et les vérifications reprennent aussitôt.
Avant de commencer
L’API REST est incluse dans Professional et Business. Créez une clé API avec Read & write sous Settings › API, et enregistrez-la comme secret dans votre CI, ici UPTIMECHECK_API_KEY.Récupérez les ID des moniteurs à suspendre. Chacun commence par mon_ et correspond à la dernière partie de l’adresse de la page du moniteur ; vous pouvez aussi tous les lister :
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H « Authorization: Bearer $UPTIMECHECK_API_KEY » | jq -r ‘.data[] | [.id, .name] | @tsv’
GitHub Actions
Ce workflow ouvre une fenêtre de 30 minutes, déploie, puis referme la fenêtre, que le déploiement ait réussi ou non. Remplacez les ID des moniteurs et l’étape de déploiement par les vôtres. Dans n’importe quelle autre CI, les deux mêmes appels fonctionnent.
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 »
Si Uptimecheck est injoignable, le déploiement a quand même lieu, sans fenêtre.
Les deux appels
POST /api/v1/maintenance démarre ou planifie une fenêtre. Envoyez title, startsAt et endsAt sous forme d’horaires ISO 8601, comme 2026-10-18T14:00:00Z, ainsi que monitorIds. Un début situé dans le passé la démarre immédiatement, et une fenêtre dure au maximum 14 jours. Le data.id de la réponse commence par mw_.Champs facultatifs : message, affiché sur les pages de statut, et notifySubscribers (false sauf si vous envoyez true), qui prévient par e-mail les abonnés des pages de statut.DELETE /api/v1/maintenance/{id} met fin immédiatement à une fenêtre en cours, ou annule une fenêtre qui n’a pas commencé. Il répond 204.
Bon à savoir
Réglez endsAt un peu au-delà de votre déploiement le plus lent. Si le job s’arrête avant la dernière étape, la fenêtre se termine quand même à l’heure prévue.Les pages de statut qui affichent ces moniteurs indiquent Maintenance in progress pendant la fenêtre et la listent avec son titre, tout comme le widget de statut. Choisissez un titre que les visiteurs peuvent voir.Un incident ouvert au début de la fenêtre est fermé, et le moniteur repart sur une nouvelle vérification à la fin de la fenêtre.Les pings de tâches cron reçus pendant la fenêtre sont enregistrés mais ne changent rien, et un ping manqué pendant celle-ci ne déclenche pas d’alerte.L’API peut aussi suspendre et réactiver des moniteurs individuels (POST /api/v1/monitors/{id}/pause et /resume). Une fenêtre est plus simple pour un déploiement, car elle se termine d’elle-même.
Tous les champs figurent dans la référence de l’API. Pour planifier des fenêtres dans l’application, voir comment planifier une fenêtre de maintenance. En savoir plus sur l’API REST.