Fifty monitors, one coffee.

You have a list of URLs — from a spreadsheet, another tool's export, or your reverse proxy config. This recipe turns it into a monitored fleet. Test first with a pls_test_ key against your sandbox, then run it live.

Input: one URL per line

# urls.txt
https://example.com
https://api.example.com/health
https://shop.lakeside.example

The loop

Each request carries an Idempotency-Key derived from the URL itself — rerunning the script after a network hiccup replays instead of duplicating:

#!/usr/bin/env bash
set -euo pipefail
: "${UP4_API_KEY:?set UP4_API_KEY first}"

while IFS= read -r url; do
  [ -z "$url" ] && continue
  name=$(echo "$url" | sed -E 's#https?://##; s#/.*##')
  curl -fsS -X POST https://app.upfour.io/v1/monitors \
    -H "Authorization: Bearer $UP4_API_KEY" \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: import-$(echo -n "$url" | shasum | cut -c1-32)" \
    -d "{
      \"name\": \"$name\",
      \"url\": \"$url\",
      \"monitor_type\": \"http\",
      \"interval_seconds\": 60,
      \"regions\": [\"default\"]
    }" > /dev/null
  echo "created: $name"
done < urls.txt

Or: the batch endpoint

POST /monitors/batch accepts a list and creates the fleet in one request — it is the same mechanism the in-app migration flow uses. See the monitors reference and try it there with a sandbox key.

Afterwards

Tighten the monitors that matter to 10 seconds (the cost preview shows the difference before you save), attach an alert plan, and put the fleet on a status page. Agencies: add "client_id": "…" to each body and the fleet lands inside the right client partition.