kprompt + Prometheus: why is my api slow — without inventing numbers

Prometheus is still the right store for cluster metrics. kprompt does not replace it, and it does not invent a latency number when the backend is missing. It binds the Prometheus you already scrape and compiles “why is my api slow?” into bounded PromQL — then narrates CPU, memory, p95, replicas, and HPA. Read-only. No silent patch.

Helm day-2 has its own deep dive. This post is the metrics sibling: detect, bind-over-install, the performance explain shape, how optimize uses the same URL, and what we refuse to claim.

Prerequisite: a Prometheus URL, not a second stack

kprompt tools reports whether a Prometheus URL is configured. Brownfield instinct is bind the scraper you already run. kprompt setup can plan kube-prometheus-stack — dry-run by default, approve-gated — but that is the exception, not the adopt path.

kprompt tools
# prometheus: configured URL — or MissingHint

kprompt config set tools.prometheus.url http://prometheus.monitoring:9090

# Only if you truly have no Prom and accept an install plan:
# kprompt setup --only prometheus --dry-run

why is my api slow — read-only explain

Performance explain is a read. It uses bounded instant and range queries for a named workload: CPU, memory, p95 latency when the metric exists, replica count, and HPA headroom. Missing Prom fails clear. Partial metrics degrade — they do not fabricate p95.

$ kprompt "why is my api slow?" -n production

# Needs tools.prometheus.url
# Narrates CPU / memory / p95 / replicas / HPA when the series exist
# Does not apply a scale or patch

Same family: why is production slow, show CPU for payment-api pods last hour. The Top 100 hub lists the observability set; this post is the contract behind those rows.

What the queries are allowed to do

Timeouts and bounded windows are part of the adapter. kprompt is not a PromQL scratchpad and not a drop-in for Grafana Explore.

optimize uses the same bind

optimize my cluster is a separate read-only report: inventory always, idle and rightsizing when Prometheus usage vs requests supports it, HPA hints from objects. --approve on the optimize prompt does not patch Deployments. Suggested scale/patch plans are follow-ups with their own approval.

kprompt "why is my api slow?" -n production
kprompt "optimize my cluster" -n production
kprompt "optimize my cluster" -o json   # CI / jq — still read-only

Multi-tool: explain, then a plan

You can chain a read into a mutate: why is api slow then scale api to 4. The scale step still produces one aggregate plan and one approval. Metrics narration is not permission to apply.

kprompt "why is api slow then scale api to 4" -n production
# read evidence, then a scale PlanResult — y/N or --approve

What we are not claiming

• Not a PromQL IDE or recording-rule compiler
• Not a replacement for Grafana dashboards (those are a separate bind)
• Not a second kube-prometheus-stack by default — bind first
• Not cloud invoice / FinOps — labeled cost notes only when Prom exists
• Not auto-remediation: slow ≠ silent HPA edit
• Not a promise that every cluster has RED metrics with the names we prefer

Try it against the Prom you already have

kprompt tools
kprompt config set tools.prometheus.url http://prometheus.monitoring:9090
kprompt "why is my api slow?" -n staging
kprompt "optimize my cluster" -n staging
kprompt "delete everything in the cluster"
# expect hard deny — metrics never weaken the safety loop

Experimental on purpose. Prefer a non-production namespace while you learn the narration. If tools says Prometheus is missing, point at the URL you already scrape — do not install a second stack so the demo looks green.