During a major incident, “Which dashboard are we looking at?” should be an easy question to answer.
Instead, the conversation can turn into a collection of links. One dashboard shows the service. Another shows the region. Someone shares a storage chart, while someone else is looking at a different time window.
My proposal is simple: load the metrics around the event, rather than making people assemble the event from multiple dashboards.
A Large Scale Event (LSE) is a major incident with broad customer or service impact. It deserves a shared view built for that specific event, not another permanent dashboard that somebody has to maintain forever.
Start with the event context
When an LSE is declared, we should already be capturing its incident ID, affected services, suspected regions, start time, and known customer impact. Some of that information will be incomplete. That is fine, as long as the dashboard makes the uncertainty visible.
Use that context to load relevant panels from maintained templates. Apply a common time window and the appropriate service and region filters. Keep the incident ID attached to the view so responders can find it from the incident record.
Dynamic does not have to mean generating new queries during an outage. Start with queries the service teams already trust, and change their scope based on the event.
Show impact before infrastructure
Imagine an object storage event affecting reads in one region. The opening view should help answer whether requests are failing, how latency has changed, and which customers or workloads are affected where that information is available and permitted.
Storage server health, network drops, and metadata database behavior belong underneath that view as investigation detail.
A fleet average should not hide a badly affected customer. Equally, one unhealthy server should not automatically be presented as widespread customer impact.
The first screen should explain what the event is doing to customers. The next layer should help engineers investigate why.
Include a comparison with conditions before the event, and label missing or stale data. An empty chart is not evidence that the service is healthy.
Let the view change as understanding improves
The initial scope is a starting point, not a conclusion. Responders might discover that a regional issue spans several regions, or that the apparent storage problem originates in a shared dependency.
They should be able to expand the scope, add a relevant panel, and correct filters without rebuilding the dashboard. Keep those changes visible so everyone knows what they are looking at.
Do not quietly remove a signal because the latest hypothesis no longer includes it. Preserve useful panels and mark when the scope changed. Maintain access restrictions too: an event dashboard should not expose customer information that its viewers could not otherwise access.
Keep the normal service dashboards. This event view brings the relevant evidence together; it does not replace ongoing monitoring.
Archive the dashboard after the review
An event dashboard should have a lifecycle.
I would archive it once 30 days have passed since the LSE ended and its Post Incident Review (PIR) has been published. If the review is still open, keep the view available and flag it for follow-up rather than archiving it blindly.
Before archiving, preserve the event time range, panel definitions, filter changes, annotations, and the relevant metric snapshots or exports under the organization’s retention and access policies. Link that evidence from the PIR. Saving a dashboard definition alone will not preserve metric data after the underlying retention period expires.
Archiving should remove the view from the active incident list, not erase the evidence. Any reusable panel improvements can go back into the maintained templates.
The goal is not to collect more dashboards. It is to give everyone working the event a consistent place to understand impact, investigate, and confirm recovery. Once that work is finished, preserve what matters and clear the active workspace.