A retailer with branch stores gets an outage page every night when bandwidth spikes during the known backup window and then falls back to the daytime pattern. What should the assurance team do before calling that spike an incident?
Select an answer to reveal the explanation.
Short Explanation
A fire drill that rings at the same hour every night is not a blaze. You compare the retailer's backup spike with the normal shape of that window before you call it an outage. The trap is paging the first rise above the daytime line.
Full Explanation
Bandwidth at these branch stores has a known nightly shape: the backup runs, the chart rises, and the line returns to the daytime pattern when the job finishes. That repeating shape is normal behavior, so the assurance decision is to lay tonight's spike on a baseline of the backup window and see whether it matches. A match means the page is a scheduled transfer, not a new incident. Paging from the first sample that climbs above the daytime line discards the schedule the stores already follow and treats a planned job as an outage. Raising the threshold until the nightly chart stays quiet does not record normal behavior; it only stops the chart from speaking, and a genuine failure that lands in the same range goes silent with the backup. Replacing the bandwidth metric with a count of tickets the desk opened reports how busy people became, not whether the path or the backup was healthy. Exam caveat: a baseline has to cover the cycle you are judging, and a threshold lifted until the picture is blank is not that baseline. Operational check: overlay tonight's spike on several recent backup windows for the same stores and confirm the timing and the shape agree before you open an incident.