Reports

Incident Reports let operators schedule recurring, shareable summaries of their incidents. Each report covers a complete period — a day, week, or month — and is delivered automatically to the people who need to see it.

Report Specs

Reports are created and managed on the Reports page (/app/reports). Creating, editing, and deleting report specs is admin-only. The list shows each spec's cadence, next scheduled time, and recipient count. Specs that include external email recipients are marked with an External label.

A report spec defines:

• Name — A short label for the report.
• Cadence — Daily, Weekly, or Monthly. The report covers the last complete period for that cadence, evaluated in the organization's timezone.
• Send hour — The hour of day (0–23, organization timezone) at which the report is generated and sent.
• Link validity (days) — How long a shared report link stays valid.
• Filters — Restrict which incidents appear in the report. You can filter by incident statuses, monitor types, data sources, and tags. Each filter is optional; leaving one empty applies no restriction on that dimension. The data sources filter limits the report to incidents from monitors that read the selected data sources — useful for a device-specific report. For the tags filter: within a single tag category, any matching tag is sufficient (OR logic); across categories, a monitor must carry at least one matching tag in each selected category (AND logic).
• Recipients — Two kinds. Email recipients are external people who do not have a Pulse login; their copy is published to a password-protected public URL emailed to them directly. Pulse users and teams are members of your organization; picking a team sends the report to everyone in it. Team membership is resolved each time the report is generated, so people who join a team later are included automatically.
• Enabled — When off, the report is saved but will not generate automatically on its cadence. You can still generate it manually.

Generation

Reports generate automatically on their cadence at the configured send hour. Admins can also open the Actions menu on a spec and choose Generate now to produce a report immediately. The same Actions menu contains the Delete option to remove a spec.

Report History

Every generated report is frozen — it captures the incident data at the moment it ran and never changes afterward, even as the underlying incidents are acknowledged, resolved, or edited.

A spec's past reports are listed on its detail page under Recent reports, each showing its period, when it was generated, and when it expires. The list shows the most recent reports first; use Older and Newer to page through the history.

Reports are kept until they expire. Once a report passes the expiry date shown next to it — its spec's Link validity (days) counted from when it was generated — it is removed automatically, both from this list and from the shared link its recipients hold. If you need a report to stay available longer, raise Link validity (days) on the spec before the reports you care about are generated.

What a Report Contains

Each report summarizes the incidents in its period across several sections:

• Headline counts — Incidents opened, resolved, and still open, plus MTTA and MTTR.
• Volume & trends — How incident volume changed over the period.
• Status at end of period — How many incidents were Unacknowledged, Acknowledged, or Resolved when the period closed.
• When incidents start — Onset heatmap broken down by weekday and hour.
• Where incidents cluster — Incidents grouped by monitor type, by tag, and by top monitors.
• Responder load — How the response workload was distributed across your team.
• Reliability — Objectives first: for each objective, what it promised (target), what it achieved, how much of the period was actually measured, and how much of the error budget was spent. An objective measured on too little of the period reports Not enough data rather than a figure. Under each objective sits its error budget burndown, showing how the budget was spent across the period — the line starts full and only falls, so its slope is the burn rate and the zero line is the point the promise was used up. Then recurring monitors and system events over the period.
• Incident detail — A filterable, sortable, exportable table of individual incidents.

Viewing a Report

How a report is opened depends on who is viewing it.

Pulse users — whether picked individually or through a team — open reports in-app, at an authenticated view that needs no password. The report is reachable from the spec's report list, and is linked directly from the in-app notification and email they receive.

External email recipients open reports through a password-protected shared link. Each recipient receives their own distinct random password, emailed to them once — it is never stored. Opening the link prompts for that password and then shows the report. The public report viewer includes a language toggle (EN / DE) so recipients can switch the report's display language. Links expire after the spec's Link validity (days).

Delivery

When a report generates:

1. Email recipients are emailed their personal shared link together with their password.
2. Pulse users, including the members of every selected team, receive an in-app notification and an email that links to the authenticated in-app view. Someone who is both picked individually and part of a selected team is notified once, not twice.

See Incidents for details on the incidents that feed these reports.