PromQL: Querying Time Series Data as Vectors
PromQL treats metrics as vectors of values over time, letting you slice and aggregate system state. It's used for Grafana dashboards and Alertmanager rules. The footgun: applying rate() to a gauge instead of a counter produces silent, nonsensical results.
Why it exists
Monitoring systems produce vast amounts of time-stamped data. We need a language not just to retrieve a specific metric, but to select, filter, and aggregate across thousands of related time series to understand system behavior, calculate rates of change, and identify trends.
The mental model
PromQL is a functional language for operating on vectors of time series data. Instead of thinking "get me the value of http_requests_total," you think "give me the set of all http_requests_total time series, and then calculate the per-second rate of increase for each one over the last 5 minutes." The core data types are vectors (sets of time series), which can be instant (one value per series) or range (many values per series).
How it works
A query selects a set of time series based on metric names and labels, creating a vector. Functions and operators then transform this vector. For example, rate(http_requests_total{job="api"}[5m]) first selects all time series named http_requests_total with the label job="api", creating a range vector with 5 minutes of data. The rate() function then calculates the per-second average rate of increase for each series in that vector, returning a new instant vector with the results. Queries can be instant (evaluated at one moment) or range (evaluated at steps over a time window, used for graphs).
When to use it
Use PromQL for any interaction with Prometheus data. This includes building dashboards in tools like Grafana, defining alerting conditions in Alertmanager, running ad-hoc queries in the Prometheus UI to debug an issue, and creating recording rules to pre-calculate expensive queries.
When not to use it
PromQL is designed for numerical time series, not for querying logs or unstructured string data. For full-text search or complex log analysis, use a dedicated logging system like Loki or Elasticsearch. It is not a general-purpose database query language; it is highly specialized for its time series data model and cannot be used for arbitrary data mutations or complex joins in the traditional SQL sense.
One canonical example
A common task is to find the 95th percentile request latency over the last 5 minutes, broken down by API endpoint. The query might look like this: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, path)). This calculates the rate of requests falling into each latency bucket, sums them up by path, and then uses histogram_quantile to calculate the 95th percentile value from that aggregated histogram data.
Interview question
Which statement best captures PromQL's fundamental mental model for querying time series data?
- a.It operates on vectors, which are sets of time series, applying functions to select, filter, and aggregate them.Correct
- b.It views data as a stream of events, allowing real-time processing and pattern matching.
- c.It uses a relational database model, joining different metrics based on shared labels.
- d.It treats each metric as an individual scalar value, which is then combined with others using arithmetic operations.
Why? this is the answer
The card states that "PromQL is a functional language for operating on vectors of time series data" and that "The core data types are vectors (sets of time series)". Option D is incorrect because PromQL fundamentally operates on sets of time series (vectors), not individual scalar values initially.
Just read this? Test yourself on what you have been reading.
Read the original → prometheus.io
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles