Incidents

Incidents represent a period of degraded or failed service that requires attention. They are created automatically when a monitor detects a problem, or manually by a team member.

Incident Lifecycle

Every incident follows a defined lifecycle:

1. Unacknowledged -- The incident has been detected but no one has responded yet. Shown with a red Unacknowledged badge.
2. Acknowledged -- Someone has seen the incident and is working on it. Shown with an amber Acknowledged badge.
3. Resolved -- The underlying issue has been fixed. Shown with a green Resolved badge.

Creating an Incident Manually

You can manually create an incident from the incident list page. This is useful when you need to trigger an escalation policy for a situation not detected by a monitor.

To create a manual incident:

1. Open the Incidents page.
2. Click the Create Incident button in the toolbar. On mobile, this button appears as a floating action button fixed at the bottom-right corner of the screen.
3. Fill in the form:
   • Title (required) — A short description of the incident.
   • Description (optional) — A detailed description, supports Markdown.
   • Escalation Policy (required) — The escalation policy to trigger. The first available policy is pre-selected.
4. Click Create.

The incident is immediately created and the selected escalation policy is triggered. You can then acknowledge and resolve it like any other incident.

Viewing Incidents

The incident list shows all incidents with filtering by status. By default, active incidents (Unacknowledged + Acknowledged) are shown.

The sidebar shows a count badge on Incidents when there are active incidents (unacknowledged or acknowledged) open in your organization, and a separate badge on My Incidents for incidents you have acknowledged but not yet resolved. Badges refresh every minute; they are hidden when the count is zero. When the sidebar collapses to icon-only mode each badge shrinks to a small dot to signal that attention is needed.

The My Incidents sidebar entry is a shortcut that opens the incident list pre-filtered to incidents you have acknowledged — a quick way to see what you are actively working on.

• Search -- Find incidents by title or associated monitor name
• Status Filter -- Toggle visibility of each status type
• Incident Type -- Filter by how the incident was triggered: monitor failure, system incident, or manual incident
• Monitor Type -- Filter by the type of monitor that triggered the incident (Heartbeat, CVE, Trigger, Condition, Objective, OPC UA Alarms & Conditions)
• Tags -- Filter by tags assigned to the monitor that triggered the incident
• Escalation Policy -- Filter by the escalation policy the incident is escalating under. This reflects the policy in use at the time the incident was raised, not any policy later reassigned to the monitor.
• Acknowledged By -- Filter by the team member who acknowledged the incident. Select (me) to show incidents you acknowledged.
• Resolved By -- Filter by the team member who resolved the incident. Select (me) to show incidents you resolved.
• Time Range -- Filter incidents by a time window. Click the clock icon to open the picker. Choose a quick preset or set a custom date and time range. Future dates cannot be selected. With a quick preset, such as Last 8 hours, incidents that are still open are always listed, however long ago they started, so the list matches the count in the sidebar. A custom range lists only incidents that started within it.
• Auto-Refresh -- The list automatically refreshes every 5 seconds

A count next to the status chips shows how many incidents match the current filters. When the list reaches its maximum size, the count reads Newest N of N+ with a tooltip suggesting you narrow the filters or time range to see older incidents.

On mobile, the search field is hidden by default — tap the search icon in the toolbar to reveal it. Tapping the icon again collapses the field and clears any active search.

On mobile, the filter controls are replaced by a Filter button that opens a bottom drawer. All filter groups (Status, Incident Type, Monitor Type, Tags, Escalation Policy, Acknowledged By, Resolved By) appear as expandable sections inside the drawer. Each section shows a count badge when filters are selected. Tap Apply to activate the selected filters or Reset to clear all draft selections. Active filters appear as read-only chips below the search bar; to change a selection, open the drawer again.

Each incident card in the list shows its status badge, monitor type, the tags assigned to the triggering monitor, and a brief cause. When the cause is identical to the incident title — common for simple monitor alerts — the cause line is omitted to reduce repetition.

A system incident has no monitor, so its card shows what kind of incident it is instead — for example Gateway disconnected, Firmware changed, Module removed or New asset. A card for an incident about the asset register also says which station it concerns and what changed: the station's name (or its address, if it has none), its address, and the firmware before and after, the removed module's order code, or, for a new station, its address. Everyone who can see incidents sees this line, without a link to the station, as long as your license includes the asset register.

Incident Details

Click on an incident to see its full details.

The detail page includes:

• Status -- Current incident state, shown as a colored text badge
• Related Monitor -- Link to the monitor that triggered the incident
• Asset -- For an incident about an asset in the asset register, the asset it concerns, its address and, for a firmware change, the firmware before and after and the module it was read on — its rack and slot (or No rack position for a PROFINET device), order code and serial number — or, for a removed module, the module's rack and slot (or Module removed alone for a PROFINET device), order code and serial number, or, for a new asset, the module the scan found it as — its rack and slot, order code and serial number. Everyone who can see incidents sees this, read-only, so a member paged for the incident knows what they acknowledge. Administrators also see a link to the asset. Shown only when your license includes the asset register (see Firmware changes on assets, Modules removed from assets and New assets on scanned networks)
• Timestamps -- When the incident started, was acknowledged, and resolved
• Acknowledged By -- Which user acknowledged the incident. Click the name to filter the incident list to all incidents they acknowledged.
• Resolved By -- Which user resolved the incident. Click the name to filter the incident list to all incidents they resolved.
• Other Occurrences -- Earlier incidents raised by the same condition (see below)
• Activity Feed -- Chronological log of all events

Other Occurrences

When the same monitor condition has raised incidents before, a card appears above the Activity Feed listing those earlier occurrences. Each row links to that incident and shows when it started and how long it lasted (or still open if it has not been resolved). The section only appears when at least one earlier occurrence exists.

Activity Events

The activity feed records events such as:

• Incident started
• Incident reopened (alert fired again within the reopen window configured on the escalation policy)
• Acknowledged by a specific user
• Resolved by a specific user
• Monitor failure details
• Monitor recovery details
• Email notifications sent
• SMS notifications sent
• Push notifications sent
• Voice call notifications sent
• Voice call ringing (attempted)
• Voice call declined
• Voice call not answered
• Alert email opened by a specific user
• Escalation paused — outside operating hours (shows the time escalation will resume)
• Sender timestamp changed (a later delivery for the same trigger alert carried a different source timestamp)
• Manually escalated to specific users, teams or on-call schedules (see below)

Source timestamp on trigger incidents — When a trigger monitor has a Source timestamp rule configured and the sending system includes a timestamp in the payload, the Incident started and Incident reopened events in the activity feed show the time the sender claimed the alert fired. Alongside it, the feed shows how far that time differs from when Pulse actually received the delivery — for example, "12 minutes before Pulse received it" or "3 minutes after Pulse received it — check the sender's clock". This is evidence about the sender's clock; it never changes when Pulse considers the incident to have started. See Trigger Monitor for how to configure source timestamp extraction.

Description on trigger incidents — When a trigger monitor's Incident description rule extracts text from the webhook payload, that text is shown on the incident detail page rendered as Markdown. A paging system's alert body often contains prose — links to the runbook, a list of affected assets, context that does not fit a title — and Markdown lets that formatting come through. When the description and the cause would say the same thing, the cause subtitle is hidden to avoid repeating it.

Escalating an Incident Manually

Sometimes the right people are not the ones the escalation policy would page next — an operator sees an alarm and knows the electrical maintenance team has to handle it, or has already acknowledged an incident and needs to pull in a specialist. Escalate sends a direct, immediate notification to people you choose.

To escalate an incident:

1. Open the incident detail page.
2. Click Escalate… (available until the incident is resolved — also on acknowledged incidents).
3. Pick one or more users, teams or on-call schedules. A team notifies all of its current licensed members; an on-call schedule notifies whoever it puts on call at that moment.
4. Tick the channels to alert them by: Call, SMS, E-mail, or Push notification. E-mail and push are pre-selected.
5. Click Escalate.

The chosen recipients are notified immediately, with a note naming who escalated to them, and the escalation is recorded on the activity feed together with the notifications that went out.

A few things to know:

• Manual escalation is additive: the automatic escalation policy keeps running on its own schedule until someone acknowledges the incident. Escalating never silences the policy.
• A manual escalation reaches the chosen people even outside their configured operating hours — it is a deliberate, named page.
• Recipients of a manual escalation also receive the follow-up notifications when the incident is later acknowledged and resolved.
• The activity feed names the on-call schedule you escalated to, not the people it resolved to — who was on call at that moment is visible in the notification entries that follow it.

Push Notifications

When an incident is created and an escalation step with push notifications enabled is triggered, recipients receive a push notification on their registered devices. When the incident is later resolved, those same recipients receive a follow-up push notification confirming the resolution.

Comments

You can add comments to an incident's activity feed to share updates, context, or next steps with your team.

To add a comment:

1. Open the incident detail page.
2. Click Add Comment.
3. Write your comment — Markdown is supported, including task list checkboxes (- [ ] item, - [x] done).
4. Click Submit.

The comment appears in the activity feed, visible to all team members.

Actions

From the incident detail page, you can:

• Acknowledge -- Mark the incident as seen and being worked on
• Resolve -- Close the incident as fixed
• View Monitor -- Navigate to the related monitor's detail page

If you resolve an incident while its monitor is still unhealthy, Pulse warns you before proceeding: resolving in this state immediately raises a new incident, and the comments and activity history of the current incident stay with it. The action button changes to Resolve anyway to confirm you want to proceed.

On mobile, the Acknowledge or Resolve action also appears as a full-width button pinned to the bottom of the screen for easy one-handed access. Tapping it opens a confirmation drawer before the action is carried out. If the monitor is still unhealthy, the confirmation drawer shows the same warning. The button disappears once the incident is resolved.

System Incidents

Pulse automatically raises system incidents when it detects operational issues that require administrator attention. These incidents appear in the same incident list as monitor-triggered incidents and trigger in-app notifications to all organization admins.

Most system incidents resolve automatically once the underlying condition clears — you do not need to resolve them manually. The exception is incidents about the asset register: a firmware change, a removed module or a new device is something that happened, not a condition that clears, so these incidents stay open until someone acknowledges and resolves them.

Incident	Cause
Email delivery failure	An SMTP server failed to deliver a notification email.
No one available for escalation	An escalation policy was triggered but no recipient could be reached.
No one on call for [schedule]	A configured on-call schedule has no coverage during active operating hours.
Gateway disconnected	The appliance lost its connection to the Pulse gateway and could not reconnect.
Gateway enrollment failed	The appliance has not completed gateway enrollment. This appears during first-boot setup and resolves automatically once enrollment is finished.
Collector disconnected	A remote collector that data sources are assigned to has been disconnected for more than two minutes, or has not connected within ten minutes of being registered. Resolves when it connects.
No valid license	The organization has no active license. Some features may be limited.
License expiring soon	The active license is close to its expiry date.
OPC UA certificate expiring soon	Pulse's OPC UA client certificate is close to its expiry date. Resolves once the active certificate is valid well beyond it again — see Rotation.
Firmware changed on an asset	A scan or an S7 data source read a different firmware version on a module of an asset in the register. Does not resolve on its own. See Firmware changes on assets.
Module removed from an asset	Scans proved that a module is no longer in its rack on an asset in the register. Does not resolve on its own. See Modules removed from assets.
A new asset appeared on a scanned network	A scan found a device at an address an earlier scan of the same network had covered and found empty. Does not resolve on its own. See New assets on scanned networks.

Firmware changes on assets

When a network scan, or an S7 data source re-reading the module every 10 minutes (see What data sources tell the register), reads a different firmware version on a module than the asset register holds for it, the register records the change in the station's History and Pulse raises a Firmware changed on an asset incident. An unplanned firmware change on a controller is worth a look: it can be a maintenance job nobody announced, or something worse.

• One incident per change. Two modules updated in one scan raise two incidents, and a module that changes again later raises a new one.
• Only with the asset register in your license. Without it, the change is still recorded in the station's history, but no incident is raised.
• Only for recent scans. A scan that is added to the register more than 24 hours after it finished records the change without raising an incident — it is history by then, not news. A change a data source reads is news when it is read, and raises its incident then.
• Not for decommissioned stations. A decommissioned station still records its changes, but pages nobody.
• Not inside a maintenance window. A change made wholly inside one of the register's maintenance windows — from the scan or data source that last read the old firmware to the one that read the new one — is recorded and marked as made in the window, and raises no incident.
• The title names only the kind of change. Everyone who can see incidents sees it. The incident page shows everyone which station it concerns — its name, address, the firmware before and after, and the module the change was read on, by its rack and slot, order code and serial number — so a member paged for the incident knows what they acknowledge. On a station with several CPUs or communication processors, the module tells you which one changed. Administrators also see a link to the station, as the asset register is theirs. The incident list shows everyone the station's name and address and both firmware versions, without the link.
• It follows the station. If you merge the station into another, the incident moves to the station you keep; unmerging moves it back.

Like other system incidents, it notifies all organization admins in the app. By default it does not escalate; an administrator can choose an escalation policy for it in the asset register's settings, and it then escalates through that policy — for example only outside working hours. See Routing register incidents. Once you have confirmed the change was intended, acknowledge and resolve it.

Modules removed from assets

When network scans prove that a module is gone from a station in the asset register, the register records the removal in the station's History and Pulse raises a Module removed from an asset incident. A module pulled from a rack is a change worth knowing about, whether it was a planned replacement or not.

A scan that simply does not find a module is not enough. The register records a removal only when it is proven:

• Another module answers at its slot. A scan reads another module, with an order code and serial number of its own, at the module's rack and slot, through the address the module was last read through.
• Two scans miss it. Two scans that could have seen it — they covered the module's address, reached the station and got an answer from the module's slot — did not find it, and no scan found it in between. The first such scan is remembered; the second records the removal.

Only modules with an order code and a serial number, read over S7 at a rack and slot, take part. When a different controller has taken over a station's address, the register records the station as replaced instead, and raises no removal for its modules.

The incident follows the same rules as a firmware change:

• One incident per removed module. Two modules removed in one scan raise two incidents.
• Only with the asset register in your license. Without it, the removal is still recorded in the station's history, but no incident is raised.
• Only for recent scans. A scan that is added to the register more than 24 hours after it finished records the removal without raising an incident.
• Not for decommissioned stations. A decommissioned station still records its removals, but pages nobody.
• Not inside a maintenance window. A removal made wholly inside one of the register's maintenance windows — from the last scan that found the module to the scan that recorded the removal — is recorded and marked as made in the window, and raises no incident.
• The title names only the kind of change. The incident page shows everyone which station it concerns — its name and address, and the removed module's rack, slot, order code and serial number. Administrators also see a link to the station. The incident list shows everyone the station's name and address and the removed module's order code, without the link.
• It follows the station through a merge and an unmerge.

It notifies all organization admins in the app and, if an administrator has chosen one, escalates through the register's escalation policy (see Routing register incidents). If a module shows up again in a later scan, the register records it as added again; the incident stays open until you resolve it.

New assets on scanned networks

When a network scan finds a device at an address where an earlier scan of the same network found nothing, the asset register adds it as a new station, with an entry in its History, and Pulse raises the incident A new asset appeared on a scanned network. A device that nobody registered turning up on a plant network is worth a look: it can be a laptop plugged into the wrong switch, a replacement nobody announced, or something worse.

A device is only new if an earlier scan could have seen it there. Pulse raises the incident only when an earlier scan that finished:

• ran on the same appliance or collector — another collector looks at the network from somewhere else, and its first scan finds everything for the first time;
• covered the device's address — for a controller, on the port the scan found it on now. A scan that looked only on port 102, the standard S7 port, says nothing about a controller found on port 1102;
• looked with the method that found the device now, and that method ran to the end — S7 for a controller, OPC UA for an OPC UA server. A scan whose S7 part failed proves nothing about the addresses it set out to scan.

So the first scan of a network raises nothing: every device on it is new to the register, but none of them is news. Neither does the first OPC UA scan of a network that was only scanned over S7 before, for the OPC UA servers it finds.

Nor is an incident raised for:

• a replaced device — a different controller answering at the address of a registered station. The register records the station as replaced instead.
• a host only the network sweep saw — an address that answered the sweep and none of the protocols scanned for. Addresses handed out automatically come and go.
• a PROFINET device — PROFINET discovery does not scan addresses, so there is no earlier scan to compare with.
• a station next to a registered one — a new station at an address where the register already holds another station, such as a controller's built-in OPC UA server answering for the first time next to the controller.

The incident follows the same rules as a firmware change:

• One incident per new station. Two new devices in one scan raise two incidents.
• Only with the asset register in your license. Without it, the station is still added to the register, but no incident is raised.
• Only for recent scans. A scan that is added to the register more than 24 hours after it finished adds the station without raising an incident.
• Not inside a maintenance window. A device that appeared wholly inside one of the register's maintenance windows — from the start of the earlier scan that found its address empty to the scan that found it — is added and marked as found in the window, and raises no incident.
• The title names only the kind of change. The incident page shows everyone which station it concerns — its name and address and, for a controller, the module the scan found it as, by its rack and slot, order code and serial number (the CPU, unless another module identified the station). An OPC UA server, and a station recorded before Pulse named this module, shows none. Administrators also see a link to the station. The incident list shows everyone the new station's name and address, without the link.
• It follows the station through a merge and an unmerge.

It notifies all organization admins in the app and, if an administrator has chosen one, escalates through the register's escalation policy (see Routing register incidents). Once you know what the device is, acknowledge and resolve the incident; if it should not be there, take it off the network, and decommission its station.