GitHub Action: assert healthy after deploy

Available since v1.0.0 (May 2026).

What it does

The uptimemonitoring/assert-healthy action polls a monitor and fails the workflow step if the monitor doesn’t report healthy within a timeout window. Built for post-deploy health gates.

Minimal workflow

- name: Verify deploy health
  uses: uptimemonitoring/assert-healthy@v1
  with:
    api-key: ${{ secrets.UPTIMEMONITORING_API_KEY }}
    monitor-id: ${{ vars.MONITOR_ID }}
    timeout: 120

Inputs

Input	Required	Default	Description
api-key	Yes	—	UptimeMonitoring API key
monitor-id	Yes	—	Monitor ID to check
timeout	No	120	Max seconds to wait for healthy
base-url	No	https://api.uptimemonitoring.com	API base URL

Outputs

Output	Description
healthy	true or false
last-status	Last observed monitor status
last-region	Region of last check
last-ttfb-ms	TTFB of last check

Advanced usage

Custom timeout

- name: Verify deploy health
  uses: uptimemonitoring/assert-healthy@v1
  with:
    api-key: ${{ secrets.UPTIMEMONITORING_API_KEY }}
    monitor-id: ${{ vars.MONITOR_ID }}
    timeout: 180

If you also use Monitive Pro

Monitive Pro is a separate, full-featured monitoring product from the same team. UptimeMonitoring.com and Monitive Pro have different feature sets, pricing, and accounts. The base-url input lets the same action target either product:

- name: Verify deploy health
  uses: uptimemonitoring/assert-healthy@v1
  with:
    api-key: ${{ secrets.MONITIVE_API_KEY }}
    monitor-id: ${{ vars.MONITOR_ID }}
    base-url: https://app.monitive.com/api
    timeout: 180

Using in a matrix

The block below is a jobs.<job>.steps: fragment — drop it into a full workflow with name, on, and runs-on already declared:

jobs:
  assert-healthy:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        monitor: [1287, 1288, 1289]
    steps:
      - uses: uptimemonitoring/assert-healthy@v1
        with:
          api-key: ${{ secrets.UPTIMEMONITORING_API_KEY }}
          monitor-id: ${{ matrix.monitor }}