Monitors & incidents
Manage monitors and incidents from the CLI, including scheduling runs, triaging open issues, and reviewing recent monitoring results.
A monitor runs a test on a schedule. When a monitored run breaches an alert rule, it raises an incident. Both are scriptable from the CLI, which suits on-call automation and dashboards.
Create and control monitors
# Schedule a monitor for a test (set the cadence with --scheduling; see the link below)
ktm monitors create --product acme~web --test-id 16480 --variant "API:Prod" --scheduling "<schedule>" --start
# List, force an immediate run, pause or resume in bulk
ktm monitors list --operator acme -o table
ktm monitors force-run <monitor-id>
ktm monitors toggle --ids 12,13 --active false
See Scheduling for the cadence format and Monitoring for the concepts.
Triage incidents
# Quick health: open / warning / closed counts
ktm incidents counter --operator acme
# List open incidents, then inspect one
ktm incidents list --operator acme --status OPEN
ktm incidents get --operator acme --id 4567
# Close it once handled
ktm incidents close --operator acme --id 4567
See recent monitor runs
ktm monitoring-results list --product acme~web --monitoring-id <monitor-id>
The CLI tells you that a monitor failed. To understand why in plain language, the MCP server is usually faster: ask your assistant "why did monitor 4521 fail, and what changed?" See MCP examples.
What's next?
Last updated on