Decide whether it is real or an artifact: did upstream data change, did a join fan out, did a filter break, or did one real event drive it. Segment to localize it, compare against the source of truth, and only then explain it to stakeholders. Reporting a broken number as real is worse than catching it late — verify before you raise it.
How to answer it
Decide whether it is real before you tell anyone. A spike reported as real and then withdrawn costs more trust than a spike caught late.
Check in this order, because each step is cheaper than the next:
The pipeline. Did a load run twice, or a backfill land? Row counts for the period against the same period last week; duplicate check on the fact's grain.
The joins. A key that stopped being unique on one side of a join fans rows out, and every measure on the dashboard multiplies. The fan-out shows as row counts up with distinct counts flat.
The filters and the definition. Did a filter break, so a segment that was excluded is now included? Did someone change the metric's model?
Segmentation. Split the spike by every dimension available. A real event usually lives in one segment: one country, one product, one campaign. An artefact is usually uniform, or lives in one source system.
The source of truth. Compare against the system the data comes from. If the source agrees, it is real.
Then, and only then, explain it, with the evidence attached: "Orders up 40% on Tuesday, all from one campaign in one country, source system confirms 3,200 orders against a usual 800. Real, and here is why."
If it was an artefact, fix the cause and add the check that would have caught it, so the same spike cannot get to a dashboard twice.
What they are checking: that you verify before you escalate, and that you know the fan-out signature.
Common mistake: forwarding the dashboard screenshot with "did we do something on Tuesday?" before checking whether Tuesday loaded twice.