Incident lifecycle

Incident lifecycle

Let's explore the lifecycle of incidents and understand how Palzin Monitor manages them effectively.

Incident lifecycle

Incidents can have one of these statuses -

  1. Triggered

  2. Acknowledged

  3. Resolved

Learn more about what these states in the below page

Incident Lifecycle

1. Triggering incidents

When you add monitors, heartbeats, or service integrations to Palzin Monitor, any anomalies or issues detected will result in the creation of an incident. Each monitor, service integration, or heartbeat is treated as a distinct entity, ensuring that incidents are generated accurately. This means that you can have multiple monitors, a single website, or multiple AWS service integrations, and each of them will be treated individually to ensure the proper triggering of incidents.

Before creating an incident, Palzin Monitor performs a check for similar incidents within the specific integration. If a similar incident already exists and remains unresolved, a new incident is not created. Instead, an event is logged for the existing incident, capturing the occurrence without duplicating incident records. This proactive approach helps maintain a clear and organized incident log while avoiding unnecessary redundancy.

Avoiding duplication of incidents.

Similar incidents in resolved state are ignored. Only the incidents which are open (acknowledged or triggered state) will be checked.

2. Automatic escalations

With Palzin Monitor, you have the flexibility to assign a distinct escalation policy to each of your integrations. This feature empowers you to prioritize alerts and manage them more effectively, ensuring that critical incidents receive the necessary attention. By customizing escalation policies based on your specific requirements, you can streamline your incident management process and respond promptly to the most important alerts.

Incident Escalation Policy

Example escalation policy on Palzin Monitor

Palzin Monitor follows the escalation policy to determine alert recipients. When a new incident is created, the first alert is sent to the responders in the policy, following the specified order. In the given example, the initial alert is directed to the DevGroup Team via email, simultaneously notifying the designated team member, Bhavik, and sending an email to another team member.

After sending the alert, Palzin Monitor allows a 5-minute window for any of the assigned responders to acknowledge or resolve the incident. If no action is taken within this timeframe, Palzin Monitor automatically escalates the incident and alerts the next level of responders as per the escalation policy.

In the mentioned scenario, two responders will receive phone alerts, while an email alert will also be sent to the DevGroup Team simultaneously. This multi-channel approach ensures that the incident reaches the appropriate individuals promptly, maximizing the chances of a swift response and resolution.

Last updated: 1 year ago

Want to get started with Palzin Monitor? We offer a no-strings-attached
15 days trial. No credit card required.

It takes less than a minutes to setup your first monitoring.