Having your Incident Management Tool reflect your system architecture is a big milestone in reducing cognitive load on your on-call team.
In order to help our users move one step closer to this milestone, we recently released the functionality to add multiple alert sources to a service.
You can now model your service dashboard to mimic your actual system architecture. A simple example service dashboard of a video streaming platform would be:
Note: This is just a simple example of modeling your service incident dashboard to accurately reflect your system architecture. The actual architecture of a video streaming platform is more complex than this example.
For each service, you can see an active endpoint for the list of available integrations. Active Integrations for a service are denoted by a green dot against their name.
When an incident is triggered for a service, you will also have the details of the source of the trigger on the Incident dashboard and Incident details page.
So, when an incident is triggered for a service, the on-call team will know instantly which service has been impacted without spending a lot of time trying to dig that data out, thus reducing MTTA and MTTR and adhering to SLAs.
This in contrast with our earlier one-alert-per-service configuration, is a much cleaner, less populated service dashboard resulting in improved response times.
Benefits of the new Service Model include:
Ability to create a consolidated service dashboard in Squadcast to reflect your actual system architecture.
The Squadcast Rules engine is a service-specific entity and will hence help duplicate similar events and tag incidents across all active integrations in a service. So, if both Sentry and Prometheus are triggering alerts for the same incident, you can configure a rule to deduplicate both these alerts in Squadcast.
Decrease in Response times with clear diagnosis points of impacted services
Leverage Multiple Alert Sources in Squadcast to reflect your actual system infrastructure on your Service Dashboard
Table of Contents:
Having your Incident Management Tool reflect your system architecture is a big milestone in reducing cognitive load on your on-call team.
In order to help our users move one step closer to this milestone, we recently released the functionality to add multiple alert sources to a service.
You can now model your service dashboard to mimic your actual system architecture. A simple example service dashboard of a video streaming platform would be:
Note: This is just a simple example of modeling your service incident dashboard to accurately reflect your system architecture. The actual architecture of a video streaming platform is more complex than this example.
For each service, you can see an active endpoint for the list of available integrations. Active Integrations for a service are denoted by a green dot against their name.
When an incident is triggered for a service, you will also have the details of the source of the trigger on the Incident dashboard and Incident details page.
So, when an incident is triggered for a service, the on-call team will know instantly which service has been impacted without spending a lot of time trying to dig that data out, thus reducing MTTA and MTTR and adhering to SLAs.
This in contrast with our earlier one-alert-per-service configuration, is a much cleaner, less populated service dashboard resulting in improved response times.
Benefits of the new Service Model include:
Ability to create a consolidated service dashboard in Squadcast to reflect your actual system architecture.
The Squadcast Rules engine is a service-specific entity and will hence help duplicate similar events and tag incidents across all active integrations in a service. So, if both Sentry and Prometheus are triggering alerts for the same incident, you can configure a rule to deduplicate both these alerts in Squadcast.
Decrease in Response times with clear diagnosis points of impacted services
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.png)
