Profit.co displays two independent progress figures for every At Least Key Result: a percentage label and a visual progress bar. Knowing how each figure is calculated explains why the two don't always look proportional to each other.
Table of Contents
- What Is At Least Progress Bar Calculation?
- Why Does At Least Progress Bar Calculation Matter?
- How Does At Least Progress Bar Calculation Work?
- What Happens When You View an At Least KR's Progress Bar?
- What Do the Standard Progress and Overshoot Scenarios Show?
- What Are the Best Practices for At Least Progress Bar Calculation?
- Related Articles
- What Are Some Frequently Asked Questions About At Least Progress Bar Calculation?
What Is At Least Progress Bar Calculation?
At Least is a Key Result type where success means reaching or exceeding a defined threshold value. For this type, Profit.co computes the percentage label and the progress bar's visual scale independently, using the threshold, the logged actual value, and a calculated ceiling that is not the same as the threshold itself.
This dual calculation applies only to At Least type Key Results. Range type Key Results, which define their own explicit upper bound instead of a threshold, use a single ceiling equal to that bound, carry no doubling, and display no marker.
| Term | What It Represents |
|---|---|
| Threshold | The target value the At Least Key Result must reach or exceed |
| Actual | The current logged value for the Key Result |
| Ceiling | The computed upper bound the bar's fill and marker are scaled against |
| Marker | The vertical line on the bar showing where the Threshold sits on the Ceiling's scale |
Why Does At Least Progress Bar Calculation Matter?
Because the bar's fill is scaled against double the threshold rather than the threshold itself, a Key Result reading 66% on its label can visually fill only about a third of the bar. Without knowing this, a manager scanning a dashboard could mistake a partially filled bar for underperformance when the label already confirms the Key Result is on track.
The same fixed scaling explains why Key Results with very different threshold values, €9M, €11.95M, €26.4M, and €56.25M, all show their marker at the identical 50% position. Recognizing this pattern prevents misreading the marker's position as a meaningful comparison across Key Results.
How Does At Least Progress Bar Calculation Work?
Profit.co runs four calculations to render an At Least Key Result's progress bar. Each one uses the Threshold and Actual values already logged against the Key Result.
Step 1: Calculate the Ceiling
- Formula: Ceiling = max(2 × Threshold, Actual)
- The Ceiling stays fixed at double the Threshold unless Actual grows larger than that
- For range type Key Results, the Ceiling equals the Key Result's own explicit upper bound, with no doubling applied
Step 2: Calculate the Marker Position
- Formula: Marker position = Threshold ÷ Ceiling
- This places the Threshold on the bar's scale relative to the Ceiling
- Range type Key Results have no Threshold value and therefore display no marker
Step 3: Calculate the Fill Width
- Formula: Fill width = Actual ÷ Ceiling
- This determines how much of the bar appears shaded
Step 4: Calculate the Percentage Label
- Formula: Percentage label = Actual ÷ Threshold
- This calculation runs independently of the bar's scale, so it is unaffected by the Ceiling
Note
The Ceiling formula and the doubling behavior apply only to At Least type Key Results. Range type Key Results use their own upper bound instead.
What Happens When You View an At Least KR's Progress Bar?
The table below covers what actually appears on screen once these formulas run against real Threshold and Actual values, not the mechanics of the calculation itself.
| Scenario | What Happens |
|---|---|
| You view an At Least Key Result whose Actual has not reached double the Threshold. | Profit.co sets the Ceiling to exactly double the Threshold, so the Marker sits at 50% regardless of how large or small the Threshold is. |
| You view an At Least Key Result whose Actual passes double the Threshold. | Profit.co sets the Ceiling to the Actual value itself, so the Marker shifts left of 50% and the bar fills to 100%. |
| You view a range type Key Result instead of an At Least Key Result. | Profit.co uses the Key Result's own explicit upper bound as the Ceiling, so no Marker appears and the Fill width matches the Percentage label exactly. |
| You view an At Least Key Result whose Actual sits well below the Threshold. | Profit.co shrinks the Fill width proportionally while the Marker position stays fixed at 50%. |
| You view a parent Key Result whose child Key Result has overshot its own Threshold. | Profit.co raises the parent's Fill width and Percentage label using the combined Actual, but keeps the parent's Marker at 50% unless the parent's own Actual passes its own 2×Threshold Ceiling. |
What Do the Standard Progress and Overshoot Scenarios Show?
Two worked examples, built from the same Net Sales objective and its four Key Results, show these formulas against real values and how the results change as Actual moves relative to the Threshold.
Standard Progress Scenario
In this scenario, every Key Result's Actual sits below double its Threshold, so each Ceiling stays fixed at 2×Threshold and every Marker lands at 50%.
| KPI | Threshold | Actual | Ceiling | Marker Position | Fill Width | Label |
|---|---|---|---|---|---|---|
| Parent: Achieve NetSales 56.25M | €56.25M | €29.72M | €112.5M | 50% | 26.4% | 53% |
| KR1: Achieve NetSales 11.95M | €11.95M | €7.84M | €23.9M | 50% | 32.8% | 66% |
| KR2: Achieve NetSales 9M | €9M | €6.08M | €18M | 50% | 33.8% | 68% |
| KR3: Achieve NetSales 26.4M | €26.4M | €15.8M | €52.8M | 50% | 29.9% | 60% |
| KR4: Achieve NetSales 8.79M (range) | — | €5.32M | €8.79M | n/a | 60.5% | 60% |
KR1: Achieve NetSales 11.95M Euro (Thorsten Buhrig)
- Threshold: €11.95M, Actual: €7.84M
- Ceiling: 2 × Threshold = €23.9M
- Marker position: 11.95 ÷ 23.9 = 50%
- Fill width: 7.84 ÷ 23.9 = 32.8%. Label: 7.84 ÷ 11.95 = 66%
KR2: Achieve NetSales 9M Euro (Jan Lehmkuehler)
- Threshold: €9M, Actual: €6.08M
- Ceiling: 2 × Threshold = €18M
- Marker position: 9 ÷ 18 = 50%
- Fill width: 6.08 ÷ 18 = 33.8%. Label: 6.08 ÷ 9 = 68%
KR3: Achieve NetSales 26.4M Euro (Tobias Werning)
- Threshold: €26.4M, Actual: €15.8M
- Ceiling: 2 × Threshold = €52.8M
- Marker position: 26.4 ÷ 52.8 = 50%
- Fill width: 15.8 ÷ 52.8 = 29.9%. Label: 15.8 ÷ 26.4 = 60%
KR4: Achieve NetSales 8.79M Euro (Ralph-Theodor), range type
- Type: range (€0 to €8.79M), not At Least. No Threshold value and no Marker
- Actual: €5.32M. Ceiling: €8.79M, its own explicit upper bound, with no doubling applied
- Fill width: 5.32 ÷ 8.79 = 60.5%. Label: 5.32 ÷ 8.79 = 60%
- This is the only Key Result where Fill width and Label agree, since range type skips the 2×Threshold ceiling logic entirely
Parent: Achieve NetSales 56.250.000 Euro
- Threshold: €56.25M, Actual: €29.72M
- Ceiling: 2 × Threshold = €112.5M
- Marker position: 56.25 ÷ 112.5 = 50%
- Fill width: 29.72 ÷ 112.5 = 26.4%. Label: 29.72 ÷ 56.25 = 53%
The parent's threshold of €56.25M is the sum of the four Key Results above (11.95 + 9 + 26.4 + 8.79 is approximately 56.14M), so it rolls up the same At Least logic and follows the same fixed 50% marker behavior as KR1 through KR3.
Overshoot and Shortfall Scenario
Here, KR1 has exceeded its threshold by more than double, KR3 sits well below its threshold, and KR2 and KR4 hold steady. This scenario shows what happens to the marker and fill once an actual value crosses past double its threshold.
| KPI | Threshold | Actual | Ceiling | Marker Position | Fill Width | Label |
|---|---|---|---|---|---|---|
| Parent: Achieve NetSales 56.25M | €56.25M | €46.4M | €112.5M | 50% | 41.2% | 82.5% |
| KR1: Achieve NetSales 11.95M | €11.95M | €30M | €30M | 39.8% | 100% | 251% |
| KR2: Achieve NetSales 9M | €9M | €6.08M | €18M | 50% | 33.8% | 68% |
| KR3: Achieve NetSales 26.4M | €26.4M | €5M | €52.8M | 50% | 9.5% | 19% |
| KR4: Achieve NetSales 8.79M (range) | — | €5.32M | €8.79M | n/a | 60.5% | 60% |
KR1: Achieve NetSales 11.95M Euro
- Threshold: €11.95M, Actual: €30M, past 2 × threshold
- Ceiling: max(23.9M, 30M) = €30M. The ceiling now tracks Actual, not 2 × Threshold
- Marker position: 11.95 ÷ 30 = 39.8%, shifted left from the usual 50%
- Fill width: 30 ÷ 30 = 100%, the bar is completely full. Label: 30 ÷ 11.95 = 251%, the only place this Key Result's full overshoot is visible as a number
KR2: Achieve NetSales 9M Euro
- Threshold: €9M, Actual: €6.08M
- Ceiling: 2 × Threshold = €18M
- Marker position: 9 ÷ 18 = 50%
- Fill width: 6.08 ÷ 18 = 33.8%. Label: 6.08 ÷ 9 = 68%
KR3: Achieve NetSales 26.4M Euro
- Threshold: €26.4M, Actual: €5M, well below threshold
- Ceiling: max(52.8M, 5M) = €52.8M, still 2 × Threshold since Actual remains well under it
- Marker position: 26.4 ÷ 52.8 = 50%
- Fill width: 5 ÷ 52.8 = 9.5%. Label: 5 ÷ 26.4 = 19%
The marker only moves once Actual passes 2 × Threshold. A low actual value that stays under the threshold shrinks the fill, not the marker's position.
KR4: Achieve NetSales 8.79M Euro, range type
- Type: range (€0 to €8.79M), not At Least. No Threshold value and no Marker
- Actual: €5.32M. Ceiling: €8.79M, its own explicit upper bound, with no doubling applied
- Fill width: 5.32 ÷ 8.79 = 60.5%. Label: 5.32 ÷ 8.79 = 60%
- This is the only Key Result in this scenario where Fill width and Label agree, since range type skips the 2×Threshold ceiling logic entirely
Parent: Achieve NetSales 56.250.000 Euro
- Threshold: €56.25M, the goal, not a sum of actuals
- Actual: €30M + €6.08M + €5M + €5.32M = €46.4M
- Ceiling: max(112.5M, 46.4M) = €112.5M. The parent's own Actual has not passed its own 2 × Threshold
- Marker position: 56.25 ÷ 112.5 = 50%. Fill width: 46.4 ÷ 112.5 = 41.2%. Label: 46.4 ÷ 56.25 = 82.5%
KR1's large overshoot pulls the parent's total actual up substantially, reflected in the parent's fill and label. However, because the parent's own Actual has not passed its own 2×Threshold Ceiling, the parent's Marker still sits at 50%. A single Key Result exceeding its own Ceiling does not, by itself, push the parent past its own Ceiling too.
What Are the Best Practices for At Least Progress Bar Calculation?
- Read the Percentage label as the source of truth for an At Least Key Result's progress, since the Fill width is scaled against a Ceiling that is not the Threshold itself.
- Expect the Marker to sit at 50% for any At Least Key Result whose Actual has not crossed double the Threshold, so a fixed 50% marker across different Key Results is not a coincidence.
- Watch for Key Results where Actual has passed double the Threshold, since the Ceiling recalculates to track Actual and the Marker shifts left, changing what an on-track bar looks like.
- When reviewing a parent At Least Key Result, check whether the parent's own Actual has crossed its own 2×Threshold Ceiling, since one child Key Result's overshoot does not automatically move the parent's Marker.
- Treat range type Key Results differently from At Least Key Results, since range type uses its own explicit upper bound as the Ceiling with no doubling and no Marker, so Fill width and Label will always agree for that type.
Related Articles
- How does the Key Result weight roll-up approach work based on KPI in Profit.co?
- How does the automatic propagation of Key Result Status work in Profit.co?
What Are Some Frequently Asked Questions About At Least Progress Bar Calculation?
No. It applies only to At Least type Key Results. Range type Key Results use their own explicit upper bound as the Ceiling, with no doubling and no Marker.
No. The Marker position is always Threshold divided by Ceiling, so it starts at 50% and only shifts left once Actual passes double the Threshold. It never shifts right.
Yes. Since the label is Actual divided by Threshold and runs independently of the bar's scale, a Key Result that significantly overshoots its Threshold can show a label such as 251%, even though the bar itself can only visually fill to 100%.
Not automatically. In the standard scenario the parent's €56.25M threshold happens to equal the sum of its four child thresholds, but that value is set directly on the parent, not computed as a running total.
Execute your strategy with confidence
Connect OKRs, tasks, and teams in one place with Profit.co
