Podczas wdrożenia strona może przez minutę zwracać błędy. Uruchom okno serwisowe ze swojego pipeline’u, a jego monitory nie będą sprawdzane, nie otworzą się żadne incydenty, nie wyjdą żadne alerty, a ten czas nie obniży dostępności. Zakończ okno po wdrożeniu, a sprawdzenia od razu wrócą.
Zanim zaczniesz
REST API jest dostępne w planach Professional i Business. Utwórz klucz API z uprawnieniem Read & write w Settings › API i zapisz go jako sekret w CI – tutaj UPTIMECHECK_API_KEY.Znajdź identyfikatory monitorów, które chcesz wstrzymać. Każdy zaczyna się od mon_ i jest ostatnią częścią adresu strony monitora. Możesz też wylistować wszystkie:
curl -sS https://app.uptimecheck.com/api/v1/monitors \
-H „Authorization: Bearer $UPTIMECHECK_API_KEY” | jq -r ’.data[] | [.id, .name] | @tsv’
GitHub Actions
Ten workflow uruchamia 30-minutowe okno, wdraża zmiany i kończy okno niezależnie od tego, czy wdrożenie się powiodło. Zastąp identyfikatory monitorów i krok wdrożenia własnymi. W każdym innym systemie CI działają te same dwa wywołania.
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”
Jeśli Uptimecheck jest nieosiągalny, wdrożenie i tak się wykona, tylko bez okna serwisowego.
Dwa wywołania
POST /api/v1/maintenance uruchamia lub planuje okno. Wyślij title, startsAt i endsAt jako czasy ISO 8601, np. 2026-10-18T14:00:00Z, oraz monitorIds. Początek w przeszłości uruchamia okno od razu, a okno trwa najwyżej 14 dni. Pole data.id w odpowiedzi zaczyna się od mw_.Pola opcjonalne: message, wyświetlane na stronach statusu, oraz notifySubscribers (false, chyba że wyślesz true), które wysyła e-mail do subskrybentów strony statusu.DELETE /api/v1/maintenance/{id} natychmiast kończy trwające okno albo anuluje takie, które jeszcze się nie zaczęło. Odpowiada kodem 204.
Warto wiedzieć
Ustaw endsAt nieco później niż czas Twojego najwolniejszego wdrożenia. Jeśli zadanie przerwie się przed ostatnim krokiem, okno i tak zakończy się na czas.Strony statusu, na których widać te monitory, pokazują w trakcie okna Maintenance in progress i wyświetlają je z tytułem – podobnie jak widżet statusu. Wybierz tytuł, który mogą zobaczyć odwiedzający.Incydent otwarty w chwili rozpoczęcia okna zostaje zamknięty, a po zakończeniu okna monitor zaczyna od nowa od świeżego sprawdzenia.Pingi cron jobów, które przychodzą w trakcie okna, są odnotowywane, ale niczego nie zmieniają, a brak pingu w tym czasie nie wywołuje alertu.API pozwala też wstrzymywać i wznawiać pojedyncze monitory (POST /api/v1/monitors/{id}/pause i /resume). Przy wdrożeniu okno jest prostsze, bo kończy się samo.
Wszystkie pola znajdziesz w dokumentacji API. Aby zamiast tego planować okna w aplikacji, zobacz, jak zaplanować okno serwisowe. Więcej o REST API.