Merge pull request #13762 from mverde11/develop

Update SLM Alerts page

src/content/docs/service-level-management/alerts-slm.mdx

@@ -18,24 +18,13 @@ import slmAlertsErrorBudget from 'images/slm_screenshot-crop_alerts-error-budget
 
 import slmAlertPolicy from 'images/slm-alert-policy.webp'
 
+import slmNoHealth from 'images/slm-missinghealth.png'
 
 
 One of the promised outcomes of implementing service levels is that you'll be able to adjust your alert policies and cut notifications down to those issues that are actually damaging your client experience, and pose a risk to your business.
 
 When you set service level objectives, you can configure alerts that will inform you in case of exhaustion of your error budget before the end of the compliance period. These alerts will show you when high business impact incidents occur. When triggered, they should be given priority, and you should engage the relevant teams to start diagnosing the source of the problem.
 
-## Understand the service levels default alert policy [#alert-policy]
-
-The service levels default alert policy was introduced, at account level, so that the service levels health status is based on its remaining error budget. This improves your experience when using other New Relic products, such as New Relic Navigator and workloads.
-
-<img
-  title="SLM Alert policy"
-  alt="SLM Alert policy"
-  src={slmAlertPolicy}
-/>
-
-This alert policy will not trigger any notification, and in case you prefer not to have the entity health based on its error budget consumption, you can easily delete this policy. Although, deleting the policy is permanent and it will affect existing and new service levels.
-
 ## Alerting on error budget burn rate [#alert-error-budget]
 
 The idea behind burn rate alerts is that the error budget represents how many bad events you can afford over the SLO period; by definition, if you spend all your error budget at a constant rate, your burn rate = 1. Then, any burn rate above the tolerable burn rate would not be sustainable because you would have completely burnt the error budget before the end of the SLO period; therefore, you might want to get alerted if that's the case for a continued amount of time.
@@ -94,7 +83,7 @@ You'll need to select an existing alert policy or create a new one to continue.
 
 If you want to set a different threshold, click **Customize** and follow the steps on the alert configuration card.
 
-## Alerting on SLO attainment 
+## Alerting on SLO compliance 
 
 If you want to set up an alert for when your SLO goes below its target for an extended period, you can select the **SLO compliance** option.
 
@@ -200,4 +189,22 @@ Last, you can choose when to automatically close any open violations.
 
 ### Limitations [#limitations]
 
-New Relic alerts can aggregate up to 2 hours of data. Therefore, New Relic doesn't yet provide the ability to alert on SLO compliance over the whole SLO period.
+New Relic alerts can aggregate up to 2 hours of data. Therefore, New Relic doesn't yet provide the ability to alert on slow-burn rates.
+
+## Understand the service levels default alert policy [#alert-policy]
+
+The service levels default alert policy was introduced, at account level, so that the service levels health status is based on its remaining error budget. This improves your experience when using other New Relic products, such as New Relic Navigator and workloads.
+
+<img
+  title="SLM Alert policy"
+  alt="SLM Alert policy"
+  src={slmAlertPolicy}
+/>
+
+This alert policy will not trigger any notifications, and in case you prefer not to have the entity health based on its error budget consumption, you can easily delete this policy. Although, deleting the policy is permanent, and it will affect existing and new service levels for that account.
+
+<img
+  title="SLs without health"
+  alt="SLs without health"
+  src={slmNoHealth}
+/>