synth-investigate-check

Start with gcx synthetic-monitoring checks status <ID> to get the success rate, then view the timeline graph to see the failure pattern. The Skill classifies the failure by cross-referencing probe data against eight failure modes and reports a diagnosis with next actions.

Run a per-probe PromQL query: avg by (probe) (probe_success{job="<job>",instance="<target>"}) via gcx metrics query. Cross-reference failing probe IDs against gcx synthetic-monitoring probes list to map them to geographic regions.

All probes failing simultaneously indicates a target-side issue rather than a network problem. Common causes are the service being down, connection refused, DNS resolution failure, or an expired TLS certificate, which the Skill distinguishes using HTTP response and phase latency signals.

Yes, query (probe_ssl_earliest_cert_expiry - time()) / 86400 to get days until the earliest certificate expires. Values under 14 days indicate an upcoming expiry risk, and negative values mean the certificate has already expired.

NODATA means no Prometheus metrics are available for the check. First verify the check is enabled with gcx synthetic-monitoring checks get <ID>, then check the datasource configuration or SM stack health, and widen the timeline window before concluding NODATA.

Use this Skill only for diagnosing failures and identifying root cause. If the diagnosis reveals the check configuration needs changes such as probe selection, frequency, or assertions, route that work to the synth-manage-checks skill instead.