synth-check-status

Synthetic Monitoring Check Status

View check health, status, and timelines.

Core Principles

1. Use gcx commands exclusively — do not call APIs directly
2. Trust the user's expertise — no excessive explanation
3. Use -o json for agent processing, default format for user display
4. Show graph visualizations for time-series data

Workflow

Step 1: List All Checks

Always start with the full check inventory:

gcx synthetic-monitoring checks list

Output columns: NAME, JOB, TARGET, TYPE. The NAME suffix is the numeric check ID (e.g. web-check-1001 is ID 1001) - use that ID in the commands below. Identify the check(s) the user is asking about.

If the user specifies a check name, filter with a job glob:

gcx synthetic-monitoring checks list --job 'my-check*'

Step 2: Show Status

For all checks (overview):

gcx synthetic-monitoring checks status

For a specific check:

gcx synthetic-monitoring checks status <ID>

Only failing checks:

gcx synthetic-monitoring checks status --status FAILING

Output columns: NAME, JOB, TARGET, SUCCESS (reachability, as shown on the app's check list card, over the last 3 hours), LATENCY, STATUS. Use -o wide for PROBES_UP/PROBES_TOTAL, or -o json for all fields.

Status interpretation (threshold depends on the check's alertSensitivity: high = 95%, medium/default = 90%, low = 75%):

• OK - reachability at or above the threshold; check is healthy
• FAILING - reachability below the threshold; route to synth-investigate-check for deeper analysis
• NODATA - the backend answered but has no reachability data for the check; it may be disabled or newly created

If the command exits non-zero with an error naming checks_reachability, the stack's Synthetic Monitoring app cannot serve the status queries (it is too old, or the query failed); no rows are printed, so this is not a NODATA result. A warning on stderr naming checks_probe_count or checks_latency means only that column is empty; statuses are still valid.