En deploy kan få en webbplats att svara med fel i en minut. Starta ett underhållsfönster från din pipeline, så kontrolleras inte dess monitorer, inga incidenter öppnas, inga larm skickas och tiden räknas inte mot upptiden. Avsluta fönstret när deployen är klar, så återupptas kontrollerna direkt.
Innan du börjar
REST API:t ingår i Professional och Business. Skapa en API-nyckel med Read & write under Settings › API, och spara den som en hemlighet i din CI, här UPTIMECHECK_API_KEY.Ta reda på id:n för de monitorer som ska pausas. Varje id börjar med mon_ och är sista delen av adressen till monitorns sida, eller så listar du alla:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H ”Authorization: Bearer $UPTIMECHECK_API_KEY” | jq -r ’.data[] | [.id, .name] | @tsv’
GitHub Actions
Det här arbetsflödet startar ett fönster på 30 minuter, deployar och avslutar fönstret oavsett om deployen lyckades eller inte. Byt ut monitor-id:na och deploysteget mot dina egna. Samma två anrop fungerar i vilken annan CI som helst.
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”
Om Uptimecheck inte går att nå körs deployen ändå, utan fönster.
De två anropen
POST /api/v1/maintenance startar eller schemalägger ett fönster. Skicka title, startsAt och endsAt som ISO 8601-tider, till exempel 2026-10-18T14:00:00Z, samt monitorIds. En starttid i det förflutna startar fönstret nu, och ett fönster varar i högst 14 dagar. Svarets data.id börjar med mw_.Valfria fält: message, som visas på statussidor, och notifySubscribers (false om du inte skickar true), som mejlar statussidans prenumeranter.DELETE /api/v1/maintenance/{id} avslutar ett pågående fönster direkt, eller avbryter ett som inte har börjat. Det svarar 204.
Bra att veta
Sätt endsAt lite efter din långsammaste deploy. Om jobbet dör före sista steget avslutas fönstret ändå i tid.Statussidor som visar de här monitorerna visar Maintenance in progress under fönstret och listar det med dess titel, och det gör även statuswidgeten. Välj en titel som besökare kan få se.En incident som är öppen när fönstret startar stängs, och monitorn börjar om med en ny kontroll när fönstret slutar.Pingar från cron-jobb som kommer in under fönstret noteras men ändrar ingenting, och en missad ping under fönstret ger inget larm.API:t kan också pausa och återuppta enskilda monitorer (POST /api/v1/monitors/{id}/pause och /resume). Ett fönster är enklare vid en deploy, eftersom det avslutas av sig självt.
Alla fält finns i API-referensen. För att planera fönster i appen i stället, se hur du schemalägger ett underhållsfönster. Mer om REST API:t.