ISPBox Wiki

Outage Incidents

Published Jul 11, 2026 · Updated Jul 11, 2026 · 3 min read

How ISPBox turns a down device into an outage incident: automatic detection, impact from map topology, root-cause grouping, customer notifications, public updates, and resolution.

The incidents list showing one open incident, Eagle Knob Tower is down, with affected services and a Notified badge

An incident is ISPBox's record of a network outage. When monitoring reports a device down, ISPBox opens an incident, works out who it affects from your network map, and (if you let it) tells those customers - then closes the loop when service is restored. This is the operator's outage console: Network Map > Incidents. It is part of the Monitoring feature and needs the network maps view permission.

1. How an incident opens

Incidents are created automatically. When a monitored device (see Network Monitoring) stays down past your grace period, ISPBox confirms the outage and opens an incident. Two things make this smart rather than noisy:

  • Impact from topology - ISPBox reads the network map to find every service downstream of the failed device, so the incident already knows who is affected.
  • Root-cause grouping - if a device that fails sits below another device that is already down, the new one is filed as a child of the existing incident instead of a separate alert. One tower failure is one incident, not fifty.

You can also raise an incident manually. Either way, if auto-notify is on and enough services are affected, customers are messaged the moment it opens.

2. The incidents list

The list shows every incident newest first, with a filter for Open, Resolved or All. Each row gives the device, status, when it started and resolved, how many services are affected, and whether customers were notified. A badge at the top tells you how many incidents are open right now (or All clear). Click a row to open it.

An incident header: Open status, a timeline of started/confirmed/notified, and an impact count of affected services

3. Inside an incident

The top of an incident summarises it at a glance:

  • Status - open or resolved, the affected device, and a link to the parent if this is a downstream child.
  • Timeline - when it started, was confirmed, when customers were notified, and when it resolved.
  • Impact - the number of affected services, plus any downstream child incidents.
Affected clients table listing the customer, service, package, email and phone

Further down, Affected clients lists exactly whose service is out - name, service, package and contact details - alongside a notification log of every email/SMS sent and any related tickets.

The status page controls on an incident: an affected area label, an estimated fix time, and a feed of public updates

4. Keeping customers informed

The Status page card controls what customers see on your public status page - device names are never shown there, so you describe the outage with:

  • Affected area label - e.g. "North Village area" - so customers recognise it without you leaking network internals.
  • Estimated fix time - shown publicly as your ETA.
  • Public updates - a running feed ("Crew dispatched", "Power supply replaced, ETA 3 PM") that appears on the status page and can be deleted if posted by mistake.

Need to reach people directly? Message clients hands off to mass messaging with the affected customers pre-selected and an outage draft ready for you to edit.

5. Resolving

When the device comes back, ISPBox resolves the incident automatically (and any children that recovered with it). If it does not clear itself - or you fixed it another way - use Resolve manually. If notify on restore is on, customers who were told about the outage get a "service restored" message.