Website Incident Timeline: How to Track and Investigate Changes
When a website becomes unavailable or its behavior changes unexpectedly, knowing what happened and when can make troubleshooting much easier. An incident timeline helps connect detected problems, relevant changes, and recovery events.
What is an incident timeline?
An incident timeline is a chronological record of monitoring events associated with a website or domain. Depending on the monitoring system, it can include detected problems, changes in monitored conditions, and recovery events. It provides context that a single alert cannot.
Understand the different event types
Not every event means the same thing. Separating incidents from changes and recoveries makes the history easier to interpret.
Problem detected
A monitored check reports a problem, such as an availability failure or another condition that no longer meets the expected result.
Change detected
A monitored value or configuration differs from a previously observed state. A change may be expected, unrelated to an incident, or worth investigating.
Recovery recorded
A previously detected problem is no longer present according to the relevant check. Recovery confirms the observed status changed; it does not necessarily explain the original cause.
Events in context
Viewing events in chronological order helps establish what was detected first, what changed during the incident, and when monitoring observed recovery.
How to investigate a website incident
Start with the first recorded failure and its timestamp. Review nearby monitoring events and configuration changes, then compare them with your own deployment history, hosting logs, DNS changes, and application logs. Treat timing as a clue, not proof of causation. A change that happened first may still be unrelated to the incident.
Why change history matters
Unexpected DNS changes, modified website content, certificate problems, or changes in security-related settings can provide useful context during an investigation. A recorded difference does not automatically mean an attack: planned deployments, provider changes, and routine maintenance can produce legitimate changes too.
Event history versus incident evidence
An event history records what the monitoring system detected and when. Incident evidence is supporting data retained for closer investigation, such as a relevant observation or captured state. These serve different purposes: a timeline helps reconstruct the sequence of events, while evidence can help examine a particular finding. Neither guarantees that the root cause can be determined on its own.
What an incident timeline cannot tell you
Monitoring observes specific signals at specific times. It may not capture every intermediate change, identify who made a change, or establish why a failure occurred. Checks can also be affected by network issues, temporary provider failures, and monitoring intervals. Correlate the timeline with independent logs and deployment records before drawing conclusions.
Incident history with Viglar
Viglar monitors external website and domain signals, helping you notice availability and configuration problems as well as relevant changes. Its event records provide historical context for detected problems, changes, and recoveries.
Know before they do.
Monitor your domains and get notified when something important changes.
Get started