Track your stability score with new stability targets
The stability score is a simple and powerful metric that many organizations have adopted as a KPI. By aligning teams around application stability, it’s now easier than ever to answer the age-old development question, “Should we be working on new features or fixing bugs?”
To make this metric even more impactful, Bugsnag is now providing the ability to set stability score targets so you have full control over your release dashboard.
What are stability targets?
Since introducing stability scores last year, you’ve likely relied upon the red-yellow-green color indicator as a visual clue about the health of your apps. The three tiers are modelled after Service Level Objectives (SLO) and Service Level Agreements (SLA).
Now, you are able to control your own stability targets! For each project, you set the two stability targets you want to monitor:
- Target stability: The target value of your stability score, or your team’s SLO.
- Critical stability: A benchmark for your stability that usually includes consequences if it is not met. This should be your team’s SLA.
Target stability
Set your target stability to match whatever your team would consider to be a stable release. Anything above this target appears green in the releases dashboard. Green means go! Your software is stable, and your team can go ahead and build some cool new features for your users.
If the stability score falls below this value, your stability score will appear yellow, which is an indicator that your team should consider prioritizing stability in the short/medium term.
The target stability/SLO is a metric that many organizations communicate externally to set appropriate user expectations. Mismanaged expectations can cause two scenarios you want to avoid: users either build brittle systems that over-rely on your application, or users mistrust your application and believe it to be less reliable than it actually is.
Critical stability
Some releases need immediate attention, as indicated by the stability score indicator appearing red when the release falls below critical stability. This critical stability score is important enough to warrant a hot fix or some other swift action.
Regardless of whether this critical stability score is an explicit requirement that’s been communicated with users (as SLAs frequently are) or an implicit requirement that your team has agreed on, critical stability demonstrates a need to address stability issues rather than build new features.
Default stability targets
We know you’re busy and might not have time to set your own stability targets, which is why we’ve set up smart defaults for you. If they look good, you can leave them as-is.
- Target stability: We took the 30-day average of your project’s stability score and selected the closest preset value that’s less than your stability score.
- Critical stability: We set this value to have one fewer nine than your target stability. In other words, if your target stability is 99.9%, your default critical stability is set to 99%.
However, if you want to set your own stability targets, the next section describes the three simple steps you’ll need to take.
How to set the stability targets
1 – Go to the Project Settings page and select “Stability targets.”
2 – You can configure the target stability and critical stability values independently. There are five preset values to choose from, or you can enter a custom target value. Once you’ve made your selection, hit Save.
3 – Your new stability targets will be populated in a 30-day stability graph to give you context on how your stability target reflects your historic stability score.
Set your eyes on the target
Clichés aside, we know that every team has a different benchmark for stability. We hope this stability score target feature helps you and your team stay on top of your bugs, build new features with complete peace of mind about your stability, and continue to delight your users.
———
Learn more about stability score and get started for free with our 14-day free trial.
