Incidents
An incident is a tracked outage with an acknowledge → resolve lifecycle and a timeline you can append notes to. ViewPeek opens one automatically the first time a monitor fires an alert, and closes it automatically when the recovery alert fires — you can also open one manually for things ViewPeek didn't detect (DNS issues, upstream-provider problems, etc.).
What it is
- Title — a one-line summary ("API returning 5xx for EU clients").
- Status — open / acknowledged / resolved.
- Severity — critical (customer-impacting) or warning (degraded but functional).
- Monitor — the affected monitor (uptime / SSL / ping / sitemap).
- Timeline — opened / acknowledged / resolved / note events in chronological order.
Auto-opened vs manual
Auto-opened: ViewPeek creates an incident the first time an alert fires for an outage (after the configured alert_after threshold). Subsequent resend alerts on the same outage do NOT open a second incident — the existing one keeps accumulating timeline events. When the recovery alert fires, the incident auto-resolves with a system note.
Manual: click Open incident on the Incidents page when something happened that ViewPeek couldn't detect — e.g. a DNS change broke things for some clients but not the monitor, or an upstream provider had a partial outage you want documented. Pick the most-relevant monitor, give it a title + severity, and start the timeline.
Acknowledge vs resolve
| Acknowledge | Resolve | |
|---|---|---|
| Meaning | "Someone is on it." | "The problem is fixed." |
| State after | Acknowledged (still open) | Resolved (closed) |
| Can re-fire alerts? | Yes — the incident is still open | No — recovery has been recorded |
| Typical note | "On it, looking at the DB" | "DB pool exhausted — restarted, monitoring" |
Acknowledge is a signalling action; resolve is a terminal action. If you resolve too early and it breaks again, hit Reopen on the incident detail page.
Adding to the timeline
The text box at the bottom of an incident's detail page posts a free-text note. Use it for:
- Investigation steps ("checked nginx logs, no 5xx — must be downstream").
- Root-cause notes once you've found it.
- Follow-up actions ("schedule a connection-pool review").
- Customer communication summaries ("emailed affected users").
Notes work on resolved incidents too — that's where the post-mortem lives.
Incidents during maintenance
If an incident is auto-opened while a maintenance window covers the monitor, ViewPeek flags it with a During maintenance badge. The incident still exists (so you can review it later), but the muted alerts mean you weren't pinged. This way deploys don't pollute the inbox but you still get a paper trail.
Export to CSV
All incidents (open and resolved) plus their timeline events are part of the monthly CSV export — useful for compliance reviews, customer post-mortems, or feeding into a spreadsheet for trend analysis.
Next steps
- Go to the incident inbox.
- Schedule maintenance windows so planned work doesn't generate incidents.
- Wire Slack alerts so the team sees auto-opened incidents in chat.