Meri

One practical warning about chasing aggressive lists, since that is the road you were on: over-blocking is expensive in ways that are hard to trace.

A list that breaks a payment provider, a delivery tracking page or a work application produces a failure with no obvious cause, and the person affected does not connect it to the resolver. You will be debugging somebody's checkout for an hour.

Keep a way to disable filtering quickly for one client, and check the query log before blaming anything else on the network. Most household complaints about the internet being broken in a house like yours are the resolver, and admitting that early saves the afternoon.

It is awkward because of a design decision in the metrics model: a time series is a set of labels plus a stream of numbers, and the query language returns numbers. Labels identify a series; they are not values you can select.

The pattern that exists for exactly your case is the info metric: a series whose value is always 1 and whose labels carry the information. Version numbers, build identifiers and machine metadata are almost always published this way.

So the value being 1 is not a bug, it is the convention - the 1 means "this combination of labels exists".

Getting the label onto a panel is then a display problem rather than a query problem, and there are two routes.

Route one: let the panel render the label. Most panels let you set the displayed name from the series labels using a template with the label name in braces. For a stat panel showing a version string, this is the whole answer - the number is hidden and the label is the text.

Route two: transformations. Take the query result as a table, then use transformations to pull the label into a column, join it against another query if you need to attach it to real values, and hide the columns you do not want. This is the route when you want the label alongside a genuine measurement - a table of machines with their version and their current load.

The join is the part worth learning. Two queries, one giving the metadata and one giving the numbers, joined on a shared label, gets you the table people usually want and it is not obvious that transformations can do it.

What does not work is trying to make the query return a string. The language has no way to do it, and time spent there is wasted.

The reasoning is straightforward once stated: a variable is a property of somebody looking at a dashboard, and an alert has nobody looking at it.

A dashboard variable is resolved from the state of the page - what you selected in a dropdown, possibly what is in the URL. An alert rule runs on a schedule in the background, with no browser, no session and no selection. There is no correct value to substitute, so the system refuses rather than guessing.

That also explains why it is not a limitation somebody will lift. It is not that the feature is missing; the input does not exist at evaluation time.

So the fix is to express the alert without needing a selection, and there are two ways to do that depending on what you actually want.

One warning about the changed-paths condition specifically, since it is usually in these tangles: it interacts badly with required checks.

A job skipped because no relevant files changed may never report a status, and a merge waiting on that status waits forever. Most platforms have a setting for treating a skipped required job as passed, and it is worth configuring at the same time as you add the path rule rather than discovering it later.