A PromQL Query Builder That Doesn't Need Your Prometheus Server

PromQL is one of those languages you only half-remember. You know rate() goes on counters, you think it goes before sum(), and you'll definitely forget the le label the one time it matters.

Most tools that help with PromQL assume you already have a running Prometheus or Grafana connected to real data. That's great for day-to-day work, but not when you're:

• learning PromQL for the first time
• reviewing a teammate's query in a PR
• sketching an alert before the exporter is even deployed
• on a locked-down machine with no access to production

So I want to show a different take: the PromQL Query Builder & Explainer from AabiTech.

What makes it different

1. No Prometheus connection required

Everything runs in your browser. The builder, explanations and diagnostics work without a data source, so there's nothing to configure, no credentials to hand over and no signup.

Most query builders pull metric names and labels from a live server. That makes autocomplete accurate, but it also makes them useless without one. This tool takes the opposite trade-off: it's available anywhere, instantly.

2. It explains queries, not just builds them

Paste any expression and the Explain & lint tab gives you a component breakdown: selectors, functions, aggregations and range windows, described in plain English.

This is great for onboarding and code review. Instead of asking "what does this sum by (le, job) do?", you can read it.

3. Built-in pitfall detection

Beyond parser diagnostics, the tool flags common mistakes:

• sum() applied before rate() on counters (resets get hidden)
• classic histogram queries that may drop the le label
• overly broad regex matchers
• placeholder or example metric names left in

Take this classic bug:

sum(http_requests_total) / rate(...)   # aggregating before rate

Aggregating counters first hides resets per series. The tool nudges you toward:

sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

These are advisory heuristics, not guarantees, but they catch the mistakes that waste an afternoon.

4. Four workflows in one workspace

• Query builder: structured inputs for metric, label matchers, range function, window and aggregation
• Explain & lint: plain-English breakdown plus static diagnostics
• Templates: curated patterns for HTTP rates, 5xx ratios, p95 latency, CPU/memory, disk, down targets, Kubernetes restarts and more
• Alert rule helper: generates a draft YAML rule for an HTTP 5xx error-ratio alert

5. Honest about its limits

I appreciate that the tool says plainly what it can't do. Parser diagnostics validate syntax only. They can't confirm a metric exists, that the query returns data, or that it's efficient. Templates are starting points, and generated alert YAML is a draft to review.

That honesty matters in monitoring, where a query that "looks right" can silently return nothing.

Quick example: p95 latency

Using the templates, a classic-histogram p95 looks like this:

histogram_quantile(0.95, sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

Drop it into the editor and the explainer walks through each layer. It also reminds you that native histograms work differently.

When to use what

Situation	Best fit
Exploring real metrics and labels	A tool connected to your live data source
Learning, reviewing or drafting queries offline	This builder
Final validation before production	Your own Prometheus, always

They're complementary. Draft and sanity-check here, then validate against real data.

Try it

👉 aabitech.com/tools/promql-query-builder

Free, browser-based, no signup. I'd love to hear which PromQL pitfalls bite you most. Drop them in the comments and I'll check whether the linter catches them.