Incident Policy Framework—Use Cases

• Business intent defined incident priority
  The default priority of system generated incidents can be changed by you to priority levels defined by your business requirements.
  For example, using an incident policy rule, you can change the severity of the BGP peer down critical incident for Branch sites to be a P1 instead of the default P2.
• Escalate priority of standing incidents
  When certain incidents are left standing for a long time, you can specify an escalation policy rule to increase the priority of the incident.
  For example, if the Device Disconnected from controller incident is standing for more than 24 hours there should be an escalation rule in place to alert you and to ensure that you fix this condition.
• Suppress incidents during a maintenance window
  When you bring down a site during a scheduled maintenance window, all incidents generated during this period can be suppressed using a policy rule.
  Example, when a Data Center site goes down for scheduled maintenance, it will cause a series of incidents to be generated like Secure Fabric Down, BGP peer down, Interface down, etc. You can easily configure an incident policy to suppress all alerts and incidents originating at this Data Center site during the time period when the maintenance window is scheduled.
• System rules to suppress incidents during internet outage at a site
  When there is an Internet outage, a series of incidents may be generated because of VPNs going down. Since this is an expected issue, you can choose to suppress incidents until the Service Provider fixes the outage situation.
• Escalate Priority when Core BGP peer flaps at Data Center site
  There are some scenarios where the incidents raised and cleared are in quick succession multiple times within a short time period.  However, since the condition is cleared you are blind to such an incident in your network. You can now be aware of such flaps happening in the network, by creating a flap rule and a new Flap rate exceeded incident will also be generated to alert you.
  For example, if the standard VPN to Prisma Access flapped 3 times in 1 hour, you can be alerted for all such incidents across all Branch sites so that they can investigate if there is an underlying provider issue or if there is something else contributing to the flapping and take corrective action before becoming a reported problem.
• Suppress incidents during staging
  An incident policy rule can be used to suppresses particular incident codes that you may not be interested in being alerted about.
  For example, you may not care to see the Site Circuit Missing incident across all sites, or may want to suppress BGP down incidents for particular branch sites, since the devices are still being staged.
• Suppress incidents on unstable LTE circuit
  If you are aware of an unstable LTE circuit at a branch site, you can choose to suppress all incidents arising at the site or reduce the priority of these incidents. This allows you to only focus on unexpected issues in the network.