[EuiProgressBar] Gradient variant

[weronikaolejniczak]

Requestor

@gvnmagni @awahab07

Problem Statement

Tl;dr; Currently, the progress bar indicator is not rounded and we cannot pass a gradient value.

Lens is introducing the ability to display progress bars next to values with a value-based coloring function (conditional formatting). One of the required coloring options is a gradient that:

• can have any number of steps and colors (driven by data and customer settings; we have no control over the configuration, so the API needs to be flexible),
• should be revealed within the filled portion of the bar as the value grows, rather than always rendering the full gradient stretched to the bar's full width and clipped by the value:

Undesired	Desired
Screen.Recording.2026-05-04.at.09.01.03.mov	Screen.Recording.2026-05-04.at.09.03.42.mov

There is also a separate, related ask to update the bar style to be fully rounded, aligned with the recent badge updates, applied globally rather than as a one-off for Lens.

Proposed Solution

Two directions discussed:

1. Accept a gradient string with the existing color prop (see experimental PR [Experiment] Add gradient option to EuiProgressBar #9631). Simple and non-breaking but potentially too flexible (arbitrary directions/degrees we may not want to support).
2. Add a new palette prop (matching the API used in EuiColorPalettePicker) so consumers pass colors and the gradient is constructed internally. Stricter, consistent with existing EUI patterns, also non-breaking.

Option 2 is likely preferable for API consistency. Whichever direction is chosen, the gradient behavior must match the "revealed in available space" pattern (see ☝🏻), not the "fill and clip" pattern.

Globally rounding the bar fill should be handled as part of the same effort.

Note: the semantic question of <meter> vs <progress> came up (a future EuiMeter was floated). Consensus for now is to extend EuiProgress rather than introduce a new component.

Use Case

• [Lens] Add progress bars in tables kibana#250708

Value / Impact

• Value to end users (Kibana feature requirement) and library consumers.
• More visual consistency with recent rounded badges.
• Useful beyond Lens. Potentially for all progress bar usages.
• Opt-in. No breaking changes.

Urgency

Preferably before end of May.

Do alternatives or workarounds exist?

A plain CSS override cannot achieve the required gradient behavior. The alternative is for Kibana to fork/customize the progress bar locally for Lens Tables which we'd like to avoid given the pattern is likely reusable.

Related code or customizations

• Experimental EUI PR (gradient using color string): [Experiment] Add gradient option to EuiProgressBar #9631
• Kibana tracking issue: [Lens] Add progress bars in tables kibana#250708
• @mgadewoll has a stashed PoC from earlier exploration that demonstrates the desired "revealed gradient" behavior and can be revisited for implementation.

Additional context (Optional)

• High contrast mode (especially Windows high contrast themes, which strictly override background colors) needs to be evaluated as part of the implementation. Flagged by Lene but not yet investigated in depth.
• Indeterminate progress state should be checked separately; gradients there may need specific specs. To be defined with design.
• There is a reported size misalignment between Figma and EUI docs for EuiProgress (XL size in particular). Worth confirming during this work.

Designs or Specs (Optional)

WIP (@JoseLuisGJ)

[Nilamma19]

Hi! I’d be interested in contributing to this issue.

I was looking into supporting:
rounded progress indicators
gradient backgrounds for the indicator fill
Does this direction align with what the team has in mind? If so, I’d be happy to work on a PR.

[weronikaolejniczak]

@Nilamma19 we appreciate your interest but we only accept external contributions on issues labeled as "help wanted". I strongly encourage you to read our contributing wiki beforehand!

[gvnmagni]

Additional point to evaluate, negative values.

There are dashboards cases in which users are displaying data that goes into negative values, progress bars should accomodate this edge case with an opposite direction for the bar itself and a clear representation of zero baseline

I don't have a design yet but I can help on it if needed

[mgadewoll]

@gvnmagni Changing the direction of the progress bar itself is feasible. But we'd need to understand what's needed for "a clear representation of zero baseline".

Screen.Recording.2026-05-20.at.09.30.39.mov

[gvnmagni]

Trying to add more info and context about the baseline, apologies for being that vague.

As you already know, the whole idea is to give users the possibility to display progress bar in tables columns, displaying the values that are provided as cell content.

Since my final goal is to avoid creating a customisation of progress bar, I would love to use the EUI component but I also understand that these requests might overcomplicate the component and potentially be too much , since we probably need this only in dashboards. Please feel free to tell me that it is better to implement this on our own if you think it is the best option

Said that, in dashboards context, we have no control of data. In one of these columns we might get all positive values, alle negative values or even a mix of the two cases (think about temperatures, they could go above of below zero).

Lene's example shows perfectly what would be the expectations when values are negative, the progress bar starting from the right edge and growing to the left one. In tables columns though we could have both typologies of values and we will need to distinguish where the zero is positioned within the domain of data.

This is what I mean:

That baseline would be represented in no other way that the same progress bar border but with no rounded corners, and it could be positioned anywhere within the length of the component since we could have skewed data (eg. from -100 to 5).

I hope this can be helpful in understanding a bit better the final goal, happy to talk about this and to connect Visualisation Team with EUI in this case

[JasonStoltz]

Since my final goal is to avoid creating a customisation of progress bar, I would love to use the EUI component but I also understand that these requests might overcomplicate the component and potentially be too much , since we probably need this only in dashboards. Please feel free to tell me that it is better to implement this on our own if you think it is the best option

@gvnmagni I agree. I think this is best built bespoke by the team that needs it directly, for now, using whatever best practices or concepts we were able to convey in the POC that @mgadewoll built. I think this would make a great addition to EUI in the future as something like "EuiMeter". Please do keep us in the loop for guidance / review / assistance as needed.

[JasonStoltz]

We will consider adding gradient support for EuiProgress if we have a concrete use case.

[mgadewoll]

ℹ️ The PoC for an EuiMeter component that adds support for displaying bi-directional data was added here.