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.
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:
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.
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.
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.
However, if you want to set your own stability targets, the next section describes the three simple steps you’ll need to take.
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.
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.