Let an AI Agent Run Your Monitoring

Overview

AI coding agents like Claude Code and Cursor are good at exactly the work monitoring involves: reading a codebase to find what needs watching, correlating noisy signals into a diagnosis, and running repetitive commands without forgetting a step. This guide shows how to put an agent in charge of your upti.my workspace through uptimyctl.

Why it works: uptimyctl is a plain CLI with API-key authentication and -o json output on every command, which is exactly what agent tools consume. upti.my also publishes /llms.txt and /llms-full.txt, so assistants can learn the product before touching your workspace.

Setup

Install the CLI with either method:

# Quick install
curl -sSfL https://raw.githubusercontent.com/uptimy/uptimyctl/master/scripts/install.sh | sudo bash

# Or with Go
go install github.com/uptimy/uptimyctl@latest

For agent use, authenticate by exporting your API key (keys start with upt_):

export UPTIMYCTL_API_KEY=upt_your-api-key-here

Credential precedence is flag > environment variable > config file (~/.config/uptimyctl/config.yaml, created by uptimyctl auth login). The environment variable is the right fit for agents: no interactive login, no key written into the project.

Example 1: Bootstrap Monitoring from a Codebase

The classic first task: point the agent at your repository and ask it to set up monitoring. A prompt like "read this repo, identify our services and public endpoints, and create upti.my healthchecks for them" gives the agent everything it needs. Its plan will look like:

1. Read the codebase and identify services and endpoints
2. Generate healthcheck JSON specs for each
3. Create applications and upsert the checks via the CLI

A generated spec might look like:

{
  "name": "API health",
  "url": "https://api.example.com/health",
  "method": "GET",
  "interval": 60,
  "expectedStatusCode": 200
}

The agent then applies it:

# Create an application to group the checks
uptimyctl applications create --name "example-api" -o json

# Upsert a single check against it
uptimyctl healthchecks upsert --application <uuid> -f spec.json

# Or apply many checks at once
uptimyctl healthchecks bulk -f checks.json

Because upsert and bulk are idempotent styles of applying config, the agent can re-run its plan safely as the codebase evolves.

Example 2: Incident Triage

When something breaks, an agent can do the tedious first pass: gather the open incidents, correlate them, and summarize what is actually going on before a human looks at it.

# Agent pulls all incidents as JSON and summarizes/correlates them
uptimyctl incidents list -o json

# Drill into a specific incident
uptimyctl incidents get <uuid> -o json

# Post its findings to the incident timeline
uptimyctl incidents add-update <uuid> --message "Correlated with the 14:02 deploy; DB connection pool exhausted."

# Resolve once fixed
uptimyctl incidents resolve <uuid>

# File the write-up
uptimyctl incidents post-mortem <uuid> -f postmortem.md

The -o json flag matters here: the agent gets structured incident data it can reason over, rather than scraping a table meant for humans.

Example 3: Deploys and Maintenance Windows

CI or an agent can wrap every deploy in a maintenance window so expected downtime never pages anyone:

# Before the deploy
uptimyctl maintenances create \
  --title "Deploy v2.5" \
  --description "Rolling deploy of api and worker services" \
  --start-at "2026-08-11T02:00:00Z" \
  --finish-at "2026-08-11T02:30:00Z"

# ... deploy ...

# After the deploy
uptimyctl maintenances resolve <uuid>

For finer control, the agent can pause and resume individual checks around risky steps, and trigger an immediate check run to verify the deploy instead of waiting for the next scheduled interval:

uptimyctl healthchecks pause <uuid>
# ... risky migration ...
uptimyctl healthchecks resume <uuid>

# Immediate post-deploy verification
uptimyctl healthchecks trigger <uuid>

Config-as-Code Reconciliation

Agents are already good at diffing and reconciling code; export and import let them treat monitoring the same way:

uptimyctl export -f config.json
# Agent diffs config.json against the desired state, edits it, then:
uptimyctl import config.json

This works for promoting configuration between workspaces, keeping monitoring in version control, or letting an agent verify that what is running matches what the repo says should be running.

Other Commands Worth Knowing

• Alert rules — full CRUD over alert rules from the CLI
• Status pages — manage status pages and their groups
• Schedulers — uptimyctl schedulers list shows the available monitoring regions
• Analytics — per-check execution and rollup queries with --from/--to, useful for agents answering "how did this service do last week?"

Teach Your Agent About uptimyctl

Agents only reach for tools they know exist. Add a short note to your project's agent instructions file (for example, CLAUDE.md) so the agent knows the CLI is available, how it authenticates, and to always ask for JSON:

## Monitoring
- Uptime monitoring is managed with `uptimyctl` (upti.my CLI).
- Auth comes from the `UPTIMYCTL_API_KEY` env var; never write the key to files.
- Always pass `-o json` for machine-readable output.

With that in place, "check if anything is down and summarize it" becomes a one-line request instead of a walkthrough.