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}
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
