A logistics hub just deployed an application that has no performance history, and the first afternoon shows a tall spike. What should the team have before calling that spike an incident?
Select an answer to reveal the explanation.
Short Explanation
A new trail with no footprints has no normal pace yet, so the first steep hill is not automatically a landslide. You hold the logistics spike until you have a baseline of normal behavior for the new application. The trap is alerting on the first sample, raising the threshold until the new chart is quiet, or replacing the metric with a ticket count.
Full Explanation
The new application has no performance history, so the tall spike on the first afternoon has nothing established to be compared with. An incident is a departure from normal behavior, and normal behavior for this application has not been recorded yet. What the hub needs first is a baseline of that behavior; this single afternoon cannot provide it, and the spike stays unclassified until the comparison is possible. Paging the first afternoon sample treats the opening measurement as proof of an outage, which is circular when no healthy range exists. Raising the threshold until the new chart stays quiet from day one builds a blind rule from a sample of one afternoon and will hide both ordinary load and a later real failure. Putting a ticket count in place of the application's own metric abandons the measurement the team just started collecting and watches the desk instead of the application. Exam caveat: no history means no baseline yet, and the first spike is not automatically an incident or a reason to silence the chart. Operational check: keep the metric running through the hub's ordinary operating cycles, mark the usual range once those cycles exist, and compare a later spike with that range before you open an incident.