
To rebuild an incident from the alerts your Windows PC received, narrow Notification Logger to the incident window, search for the affected services, export the rows to CSV and copy the relevant ones into a table with time, source, message and action taken. Treat that table as a draft. The monitoring system's own logs decide what happened when.
This guide assumes Notification Logger was already running on the PC when the alerts arrived.
Decide what the notification log can show
A notification log answers a narrow question: which alerts reached this PC, and when Windows created them here. Microsoft's notification listener documentation lists the sending app and the creation time among the details Windows gives an app with notification access. That makes the log a good witness for two questions: when did we first hear about it, and what did the person at this PC see.
It is not an audit log. Several things separate a notification from the event behind it:
- Delivery can lag the event. A PC that was asleep, offline or signed out receives alerts late or not at all.
- An app can remove its notifications from Notification Center, as Microsoft's developer guide describes. The log may hold the alert or may have missed it.
- One event can produce several notifications, such as an email, a chat message and a monitoring alert, or none at all if the tool paged only a phone.
- Some apps draw their own banners instead of using Windows notifications. Those never reach the log.
Use the log to find the moments worth checking, then confirm each one in the source system.
Keep the records before cleanup removes them
Notification Logger deletes records older than the period set in Settings > General under "Clean notifications older than". The default is 14 days. Favorites are never removed by this cleanup.
As soon as you know the incident window, select the relevant rows and choose To favorites, or export the whole history to CSV as described below. Do it on the day of the incident: a review held two weeks later may find the records gone.
Narrow the list to the incident window
Start wider than the outage. If users reported trouble at 03:10, look from an hour before the first report until the all-clear. Early warnings such as a disk-space alert or a failed backup often arrive well before the visible failure.
- Select the filter icon in the Date column header and tick the days of the incident.
- Use the filter in the App column to keep the senders that matter: the monitoring tool, the browser that shows its web console alerts, the mail app, Windows Security.
- Select Group to group rows by app, then scan each group for its first and last alert.
The Time column shows hours and minutes. The CSV export includes seconds, which you need when several alerts land in the same minute. To check a single alert rather than a sequence, the arrival time guide is shorter.
For Windows' own alerts, start with the dedicated records: Protection history for Defender warnings, Update history for overnight restarts and Event Viewer for system events.
Search for the affected services
The search box matches notification text and app names and ignores case. Type a host name, a service name or a ticket number and press Enter. The search guide covers the basics; the patterns below are the ones that help during an incident.
To match several names at once, turn on Settings > General > Use regular expressions in search. One query can then cover a group of hosts or several wordings of the same failure.
| Pattern | Finds |
|---|---|
db-0[1-3] | db-01, db-02 and db-03 |
payments|checkout | Either service name |
down|unreachable|timed? ?out | Down, unreachable, timeout, timed out |
resolved|recovered | Recovery messages that close an alert |
If a pattern has a syntax error, the app searches for it as plain text. An empty result can therefore mean a broken pattern rather than no alerts. Try the pattern on a word you know is in the log.
Export to CSV and sort by time
Select Export and save the file as CSV. The export contains every row that matches the current search, across the whole retention period. The Date and App column filters and the Favorites view do not narrow it, so filter by date in the spreadsheet. The export guide covers saving and opening the file.
The file has four columns: NotificationDate, App, IsFavorite and NotificationText. A timestamp looks like 2026-10-11T03:14:07.5310000. It is this PC's local clock time, with no time-zone marker. Write the PC's time zone at the top of your notes.
In Excel, use Data > Get Data > From File > From Text/CSV, as in Microsoft's import instructions, then sort NotificationDate from oldest to newest. The format starts with the year, so it sorts in time order even if Excel keeps it as text.
Many monitoring tools report UTC. For a timestamp in cell A2 on a PC set to UTC+2, this formula gives the UTC time:
=DATE(LEFT(A2,4),MID(A2,6,2),MID(A2,9,2))+TIME(MID(A2,12,2),MID(A2,15,2),MID(A2,18,2))-2/24
Replace -2/24 with your own offset, and check whether daylight saving time changed during the incident. Some regional versions of Excel separate arguments with semicolons instead of commas. Format the result cell as date and time.
Write the timeline table
Download the incident timeline template (CSV). It has columns for sequence, local and UTC time, source, a short message summary, the action taken, who took it, where the entry was confirmed, and notes.
Copy only the rows that change the story: first warning, first customer-facing failure, escalation, mitigation, recovery. Summarize each message rather than pasting it whole; alert text can contain customer names, IP addresses or access links.
| Time (UTC) | Source | Message | Action taken | Confirmed in |
|---|---|---|---|---|
| 02:41:12 | Monitoring console (browser) | Disk 92% on db-02 | None, below paging threshold | Monitoring event log |
| 03:06:48 | Monitoring console (browser) | db-02 unreachable | On-call acknowledged | Monitoring event log |
| 03:09:30 | Customer ticket: checkout errors | Escalated to database owner | Ticket system | |
| 03:31:05 | Monitoring console (browser) | db-02 recovered | Failover confirmed | Monitoring event log |
The Action taken column comes from people, not from the log. A notification shows that an alert appeared on a screen, not that anyone read it. Fill this column from chat history, ticket notes and the on-call person's account.
Check each entry against the source system
Before the timeline goes into a report, give every row a value in Confirmed in: the monitoring event log, the ticket system, a server log or Windows' own history. A row you cannot confirm stays in the notes, marked as seen only on this PC.
Expect gaps. An empty stretch in the log can mean the PC was off, the alert went only to phones, or an app removed its notification before it was recorded. It does not show that nothing happened.
Share the timeline, not the raw export. The CSV holds every notification from the retention period that matched your search, including private messages unrelated to the incident. Delete working copies you no longer need.
Frequently asked questions
Can a notification log replace the monitoring system's own logs?
Why does the exported time differ from my monitoring tool?
Does the export include only the rows I filtered?
Will alerts from before I installed Notification Logger be in the log?
Keep a timestamped record of the alerts that reach your PC. Install Notification Logger and test it with a harmless alert before the next incident.
Get Notification Logger