Report which Prometheus this server talks to and whether it answers: the URL, auth mode, Prometheus version, hostname, external labels and retention, and whether the admin API is enabled. When the server is not configured, says exactly what to set. Call this first when a tool you expected is missing, and before trusting numbers from an instance you have not checked — kube-prometheus-stack installs look alike on every cluster, so the URL host is often the only tell.

Evaluate a PromQL expression at one instant — the current value of something, or a total/average over a window written into the expression (increase(x[24h]), avg_over_time(x[1h])). This is the right tool for almost every question; use prometheus_query_range only when the shape over time matters. Labels shared by every series are returned once as common_labels. Upstream order is kept, so sort_desc() and topk() rank the result; past limit the rest is cut and truncated is set.

Evaluate a PromQL expression over a time range, for how something changed: a spike, a trend, when it started. Each series comes back with stats (min, max, avg, last) and, with view=values, one value per step on a shared grid given by start and step (null where there was no sample) — no per-point timestamps. The step is picked for about 60 points unless given. Many series are expensive: aggregate in the query (sum by), or use view=stats with sort=max to find the outliers first.

Find metric names, with their type (counter, gauge, histogram, summary) and help text. search matches the name or the help text, so disk finds node_filesystem_avail_bytes by its description. Use this before writing a query against a metric you have not seen, then prometheus_describe_metric for its labels. Counters need rate() or increase(); summing a raw counter is the most common PromQL mistake.

Everything needed to query one metric: type, help, unit, how many series it has, and each label with its number of distinct values and examples. Read this before writing a selector — it shows which labels exist to filter and group by, and whether a label is high-cardinality (pod, uid) and so a bad thing to group by.

List label names, across everything or only on series matching a selector. To see one metric's labels with their values, prometheus_describe_metric is more useful.

List the values one label takes — every namespace, job or instance — optionally only on series matching a selector (e.g. the pods of one deployment). Use it to get exact values right before filtering on them, instead of guessing at a regex.

List the alerts Prometheus is currently firing or holding as pending, firing first and most severe first, with their labels, summary and description, plus counts by state and severity. This is Prometheus's own view: silences and inhibitions live in Alertmanager and are not applied here, so an alert listed here may not have paged anyone. An always-firing Watchdog alert is a heartbeat, not a problem.

List alerting and recording rules with their PromQL, health and state. Use health=err to find rules that fail to evaluate (their lastError says why) — a broken alert rule never fires, which looks exactly like everything being fine. Use type=record to find a recording rule's name before querying it, since a precomputed series is far cheaper than recomputing it.

Scrape health: what Prometheus is failing to collect, and why. Always returns totals and every scrape pool with an unhealthy target; then lists targets, by default only the unhealthy ones with their lastError (a 404 is usually a wrong metrics path or port, a timeout a slow exporter, connection refused a pod not listening). A target that is down means its metrics stop — queries over it go quiet rather than erroring. Only active targets: the dropped ones (filtered out by relabeling) run to megabytes and are never fetched.

Cardinality: how many series the head block holds, and which metrics, labels and label pairs account for most of them and of the memory. Use it to explain a slow or memory-hungry Prometheus, or before grouping by a label that might have thousands of values. Covers the head block only (the last ~2-3 hours), not the full retention.

Escape hatch: GET any /api/v1 endpoint the other tools do not wrap — /api/v1/query_exemplars, /api/v1/targets/metadata, /api/v1/alertmanagers, /api/v1/format_query, /api/v1/status/walreplay. The answer is the raw data of the envelope, unshaped, cut at max_chars. Read-only: only GET is ever sent. Prefer the named tools, which shape their output; this one can return megabytes.