Incident Tools & Collaboration

Watchers, attachments, templates, bulk actions, and everything else on the incident toolbar.

Beyond the core create → claim → resolve flow, an incident carries a full set of collaboration and workflow tools — some tucked into their own tab, some sitting right on the toolbar at the top of the ticket.

Watching an incident

You don't have to be the assignee to stay in the loop. From the Watchers tab, add anyone as a watcher — they'll get notified in-app and by push whenever the incident is updated, resolved, closed, or gets a new comment, without needing to be assigned. Remove a watcher from the same tab at any time.

Attachments

The Attachments tab lets anyone working the ticket upload a file — a screenshot, a log export, whatever's relevant. Each file lists who uploaded it and when, with Download available to everyone and Delete limited to the uploader, an admin, or a manager.

Escalating, transferring, and redistributing

Several distinct ways to move an incident along, each suited to a different situation:

  • Bump Priority — one click to move the incident up a priority level, for when it turns out to matter more than first thought.
  • Escalate — hands the incident to the next support tier up (for example L1.5 to L2), with a required note explaining why. This is a deliberate human decision, distinct from the automatic reassignment that happens if a ticket goes unacknowledged too long.
  • Transfer — a direct handoff to a specific person, when you know exactly who should pick it up next.
  • Redistribute — available to admins and managers, this re-runs auto-assignment to find a new owner rather than naming one yourself.

Resolving, reopening, and close codes

Resolving asks for a close code — permanent fix, workaround applied, user error, not reproducible, duplicate, auto-resolved, or no fault found — plus resolution notes. If the ticket has no caller to confirm the fix, you'll confirm functional recovery yourself instead. A closed incident can be reopened if the fix didn't actually hold, though each incident can only be reopened three times before that option locks.

Marking and resolving duplicates

The Duplicates tab links a repeat ticket to the original rather than merging the two into one record. Click Mark Duplicate, search for the parent incident, optionally explain why, and confirm — the duplicate closes with a close code of "duplicate," links to the parent, and a system comment records the reasoning. Unlink reverses this and reopens the ticket if needed. A Similar Incidents section on this tab suggests possible matches based on shared keywords in the description — a starting point to check, not a guaranteed match. If an incident has duplicates linked to it, its Duplicates tab also shows a Resolve All button to close every linked child in one action.

This same tab and the same "linked to parent" badge are also what a cascading outage uses automatically — see Cascade Detection & Major Incidents. Whether an incident got linked to its parent because someone clicked Mark Duplicate or because the system detected it cascading from a related outage, it shows up here identically.

Checking the Known Error Database

The KEDB Search tab lets you search known errors — root causes and workarounds already documented from past Problems — by keyword, symptom, or affected service, right from the incident you're working, before you start investigating from scratch.

Bulk actions on the incident list

Select several incidents at once from the list using the checkboxes, and a bulk action bar appears above the list: Assign (to a user and/or group), Close, Resolve, or Update Priority, all applied to every selected ticket at once.

That protection is specifically for alert-sourced incidents — the same duplicate/correlation logic that folds a flood of alerts into existing incidents (see Alerts) doesn't apply to incidents created directly, whether by hand, through the API, or via CSV import. Those paths are only protected by a straightforward rate limit on ticket creation, with no automatic dedup — worth keeping in mind if you're pushing incidents in from an external system at volume.

Saving a filtered view

Set up whatever combination of filters you use regularly — priority, state, category, assignee, date range, and more — then click Save current view and give it a name. Saved views show up as clickable pills above the list; optionally share one with your whole team instead of keeping it personal, and delete any view you own when it's no longer needed.

Creating from a template

For issue types that come up repeatedly, Incident Templates lets you pre-define a short description, description, resolution-notes starting point, impact/urgency, category, and a suggested runbook link. When creating a new incident, pick Use Template from the create form to pull all of that in automatically — still fully editable before you submit.

Example

An engineer notices five separate tickets this week describing the same VPN symptom. They mark the newest four as duplicates of the first, adding themselves and the on-call lead as watchers on the parent so both get notified the moment it's resolved. They attach a screenshot of the relevant error to the parent ticket, then use the Duplicates tab's Resolve All to close the four children in one action once the real fix lands — with the parent staying open until the underlying cause is actually addressed.