Color scheme "by series name" is flaky when using Calculations

  • Grafana 13.1.0 docker image running on Ubuntu host.

    • victoria-logs v1.24.0 as datasource
  • I’m trying to create a Stat panel with a count of the logs for each “server_name”. Each stat background must be coloured using “palette-classic-by-name” so it matches the traces in other panels on the dashboard.

  • I have a query (which has evolved to be in keeping with the queries used elsewhere in the dashboard) that provides the logs I need grouped in data frames for each “server_name”. The “name” for each stat is automatically set correctly to the “server_name”. I then use the Stat panel’s “Calculation” feature to get the total to display for each stat.

  • Depending on the order I do this, sometimes the colour is applied correctly, and sometimes each stat gets the same colour! No matter what I do, the colours do not survive a refresh. See video below.

  • I expected “palette-classic-by-name” to use the stat name, which displays correctly. Sometimes it does, but usually it doesn’t. This inconsistent behaviour is my main concern, since it thwarts development effort. A workaround will solve the instance of the problem but not its essence.

Screen capture: Screen Recording 2026-07-07 at 10.09.46 am

  • 00:00 : stats are displayed correctly with the correct name, but all the same colour.
  • 00:03 : turning off the calculation shows the wrong value, but the colour is correct!
  • 00:10 : setting a dummy Display Name for all sets colours back to same, as expected.
  • 00:14 : remove the Display Name does not restore colours.
  • 00:21 : restoring the calculation corrects the colours!
  • 00:26 : refreshing removes colours again.

From what I can see the problem is that the name used for colour lookup comes from state.displayName. While series[].name and config.displayName and even state.displayName for the “Value” field are all as you would hope, the state.displayName for the “Time” field is null. I don’t know how to influence this.

Welcome @liteyear to the community

Based on my implementation and testing →

Query returns multiple frames, one per server_name, each with one value field (confirmed in Table view).

Added Reduce transformation + confirmed via Rename by regex that each field was genuinely renamed to distinct values → not just Display Name override.

Color scheme correctly set to Classic palette (by series name).
Result → all Stat panels still rendered with same color , consistently, across refreshes.

Same setup works correctly on TestData (single frame, multiple named fields).

On influencing state.displayName on the Time field: I tried adding a Filter fields by name transformation (before Reduce) to strip the Time field out of the frame entirely, in case its null displayName was affecting color resolution. This did not change the outcome. There’s no exposed way via query, transformation, or panel config to directly set state.displayName on Time.

The observation that state.displayName being the lookup key as per the fieldColor.ts line you linked is consistent with everything observed, but not confirmed by tracing the actual runtime code

Workaround for now: Standard options → Add field override → hardcode a color per server_name. New server_name values will need a manually added override each time.

Thank you for the detailed reproduction.

Another observation today:

  • I got the panel in a state where only the first stat was coloured correctly. Looking through the Panel data JSON, the only difference I see between the series is not the presence of displayName, but the presence of the "palette-classic-by-name" setting! Oddly, it only appears in the first series.
    • This state is not stable. As soon as I re-applied the Color Scheme setting, the effect went away and I was back to all being the same colour. The JSON didn’t seem to change though.
  • I note that the “Table View” does not show the result of the Calculation, so I’m unable to use it to confirm the display name is intact. Your reproduction seems to suggest that the issue exists even if the query already returns a value per frame, so Calculation is not necessary. I’m not sure.

By the way, my current workaround doesn’t require manual colour overrides. I “simply” convert the frames back to a single table with each frame as a column, using two Transformations:

It works fine, albeit bypassing the original issue rather than addressing it.

color.mode missing from series[1+] is a more specific clue than the displayName theory, though the JSON staying unchanged while the rendered color broke suggests it may be a symptom, not the confirmed root cause.

Confirmed: We used a Reduce transformation (not Calculation), and the bug still occurred. So multiple frames alone trigger it → Calculation isn’t necessary.