Spike Alert Log(3.2.10)

The charts show patterns. This table shows the events. Every statistically significant spike is logged here with its date, project, volume, baseline at the time, and severity classification — so you have a complete audit trail of when your backlog experienced abnormal pressure.

For compliance purposes, this log provides evidence of when demand anomalies occurred and how they were classified — useful for post-incident reviews and capacity planning retrospectives.

What you can conclude

• Critical alerts (spikes exceeding 3× the baseline) represent the most significant demand events — each warrants a post-incident review.
• High alerts (2–3× baseline) are significant but recoverable — useful for pattern analysis over time.
• A log with no entries in a period whose days had a baseline indicates stable, predictable backlog inflow — a positive governance signal.

How this chart works

Timestamped audit table of all statistically significant spike events. Columns: spike date, project, inflow volume, baseline mean, spike ratio, alert tier (High = 2–3σ, Critical = >3σ).

The day in progress is shown at its count so far. Because the day is not yet complete, it is not compared against the rolling baseline and is not evaluated for a spike.

A spike is only evaluated once at least six observed days sit behind the day in question. At the start of a project's history, and after a long stretch with no data received, there is not yet enough behind a day to say whether its intake ran above normal, so no entry is logged for it. An empty stretch at the beginning of a project is therefore the absence of a baseline, not the absence of pressure. When no day in the selected range has a baseline yet, the panel shows "Collecting data" with the days of history so far instead of an empty log.