Azure Monitor Service Group SLI shows an inverted negative burn rate

Question

Azure Monitor Service Group SLI shows an inverted negative burn rate

Toru Makabe 0 Microsoft Employee

I am observing an unexpected Burn Rate chart for an Azure Monitor Service Group SLI created with Microsoft.Monitor/slis@2025-03-01-preview.

Configuration:

SLI type: Availability
Evaluation method: RequestBased
Baseline: 99%
Compliance period: 7 rolling days
Window size: 5 minutes
Good and total signals use Sum aggregation
Source metrics satisfy 0 <= good <= total and never contain negative values

In the attached 7-day chart:

The SLI metric is approximately 100 during healthy periods and 0 during failed periods.
The Burn Rate is approximately -10K during healthy periods and returns to approximately 0 during failed periods.
The displayed averages are 87.7 for the SLI and -8.67K for Burn Rate.

The Burn Rate series therefore appears inverted and approximately proportional to -100 × SLI, rather than representing the rate at which the error budget is consumed.

The Error Budget Remaining chart becomes negative after the budget is exhausted. A negative remaining budget may be intentional, although its exact unit and calculation are not documented. My primary concern is the Burn Rate: a consumption rate should normally be non-negative and should increase when the SLI deteriorates, but this chart behaves in the opposite direction.

Could you clarify:

What exact formula and unit does Azure Monitor use for these charts?
Is a negative Burn Rate expected?
Is this a known calculation, scaling, or portal visualization issue for RequestBased SLIs?

スクリーンショット 2026-08-25 110020

The source good and total metrics have been verified as non-negative, with the good value never exceeding the total value.In the attached 7-day chart:

The SLI metric is approximately 100 during healthy periods and 0 during failed periods.
The Burn Rate is approximately -10K during healthy periods and returns to approximately 0 during failed periods.
The displayed averages are 87.7 for the SLI and -8.67K for Burn Rate.

The Burn Rate series therefore appears inverted and approximately proportional to -100 × SLI, rather than representing the rate at which the error budget is consumed.

The Error Budget Remaining chart becomes negative after the budget is exhausted. A negative remaining budget may be intentional, although its exact unit and calculation are not documented. My primary concern is the Burn Rate: a consumption rate should normally be non-negative and should increase when the SLI deteriorates, but this chart behaves in the opposite direction.

Could you clarify:

What exact formula and unit does Azure Monitor use for these charts?
Is a negative Burn Rate expected?
Is this a known calculation, scaling, or portal visualization issue for RequestBased SLIs?

The source good and total metrics have been verified as non-negative, with the good value never exceeding the total value.

Venkatanaidu Madamanchi 0 Reputation points Microsoft External Staff Moderator

2026-08-25T05:04:46.9733333+00:00

Hello @Toru Makabe

Thank you contacting Microsoft support team and Thank you for sharing the detailed information and screenshots.

Based on the behavior shown, the Burn Rate chart does not appear to be behaving as expected. For a request-based availability SLI, burn rate is intended to represent how quickly the error budget is being consumed. Under normal circumstances, the burn rate should be non-negative and increase when availability degrades

In your case, the SLI values appear healthy (near 100%) while the Burn Rate is showing large negative values (around -10K), and the Burn Rate moves back toward zero during failure periods. Since the source good and total metrics have already been verified as valid (non-negative and with good ≤ total), this behavior does not align with the documented purpose of burn rate

At this time, there is no public documentation that describes a negative burn rate as expected behavior. Given that Service Groups and SLI/SLO monitoring are currently in Preview, this appears more likely to be a product-side calculation, scaling, or portal visualization issue rather than a problem with your metric configuration.

To investigate further, please share the SLI resource ID, the SLI configuration (in Private message), the source and destination Azure Monitor workspaces, and the timeframe during which the issue was observed. We can then review the details and engage the engineering team if needed.

Regards,

Venkat.M
Venkatanaidu Madamanchi 0 Reputation points Microsoft External Staff Moderator

2026-08-27T04:27:29.14+00:00

Hello @Toru Makabe

Could you please review the solution provided below and let us know if it helps resolve the issue? We are currently awaiting your update regarding the outcome.

Your feedback will help us determine the next steps and ensure that the issue is addressed appropriately. If you have any questions or need further assistance, please feel free to reach out.

Thank you for your time and cooperation. We look forward to hearing from you.

1 answer

Your answer

Venkatanaidu Madamanchi 0 Reputation points Microsoft External Staff Moderator

2026-08-25T05:04:46.9733333+00:00

Hello @Toru Makabe

Thank you contacting Microsoft support team and Thank you for sharing the detailed information and screenshots.

Based on the behavior shown, the Burn Rate chart does not appear to be behaving as expected. For a request-based availability SLI, burn rate is intended to represent how quickly the error budget is being consumed. Under normal circumstances, the burn rate should be non-negative and increase when availability degrades

In your case, the SLI values appear healthy (near 100%) while the Burn Rate is showing large negative values (around -10K), and the Burn Rate moves back toward zero during failure periods. Since the source good and total metrics have already been verified as valid (non-negative and with good ≤ total), this behavior does not align with the documented purpose of burn rate

At this time, there is no public documentation that describes a negative burn rate as expected behavior. Given that Service Groups and SLI/SLO monitoring are currently in Preview, this appears more likely to be a product-side calculation, scaling, or portal visualization issue rather than a problem with your metric configuration.

To investigate further, please share the SLI resource ID, the SLI configuration (in Private message), the source and destination Azure Monitor workspaces, and the timeframe during which the issue was observed. We can then review the details and engage the engineering team if needed.

Regards,

Venkat.M
Venkatanaidu Madamanchi 0 Reputation points Microsoft External Staff Moderator

2026-08-27T04:27:29.14+00:00

Hello @Toru Makabe

Could you please review the solution provided below and let us know if it helps resolve the issue? We are currently awaiting your update regarding the outcome.

Your feedback will help us determine the next steps and ensure that the issue is addressed appropriately. If you have any questions or need further assistance, please feel free to reach out.

Thank you for your time and cooperation. We look forward to hearing from you.

Answer 1

Hello @Toru Makabe

Given the values you provided, I shouldn't treat the negative burn rate as expected behavior.

Microsoft refers to burn rate as the rate at which the SLI uses up its error budget. With a 99% baseline, the error budget allowed is 1%. The burn rate should increase as failures use up that budget; a healthy SLI must not result in a large negative burn rate.

The source metrics satisfy 0 <= good <= total, but since the chart shows about -10K while the SLI is healthy and tends toward zero during failures, the series shown does not seem to match Microsoft's stated burn-rate semantics.

The current documentation provides only a conceptual explanation of burn rate rather than specifying the calculation or the units involved.

Since the SLI resource/API you're using is still in preview, the issue may be a calculation or display error in the portal rather than anything wrong with your good/total signals. In that case, I suggest you open an Azure support case and include the SLI resource ID, the ARM definition, screenshots, and sample values for the good/total metrics so the Azure Monitor team can verify the backend calculation.

Sharing these references with you:

Create service level indicators in Azure Monitor

Monitoring Service Groups with Azure Monitor

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.