Attach a Runbook
This Runbook step attaches another Runbook to the current incident.
Most use cases can be handled by configuring attachment rules at the Runbook level. But sometimes for organization and clarity, you may choose to limit which Runbooks auto-attach to incidents and only allow those top-level Runbooks explicitly attach other Runbooks based on conditions.
Use Case Comparison
Setting Runbook-Level Conditions
Let's say you have a generic Runbook that applies to all
SEV1 incidents. You have an additional Runbook that you only want to attach if it's
SEV1 and impacted components include
You could set this explicitly on the 2nd Runbook, like so:
- The caveat is that the generic
SEV1Runbook has no reference to this secondary Runbook, and vice-versa. So users would need to know to check both Runbooks for all the steps.
- This amplifies if there are even more Runbooks auto-attaching of their own volition/conditions.
Attaching a Runbook in a step
Alternatively, you can choose to limit which Runbooks auto-attach at the top level.
As an example, let's say only these three Runbooks will attach to incidents if the Severity matches, and all other Runbooks are set to
when invoked manually.
From there, we can set an explicit step inside the
SEV1 Runbook to attach the
- This is an example of Runbook layering and offers advantages in keeping your Runbooks and automations organized.
- We know that the
api-serverRunbook will never be accidentally attached to any incident unless one of the top level Runbooks explicitly calls it.
- It's easier for users to follow the chain of command - this is especially useful if a broad adjustment needs to be made to e.g. your
SEV1process. You'll enter just a single top-level
SEV1Runbook, and from there, users will see which downstream Runbooks are called by this one and may also need adjustment.
It's a different way to organize and automate Runbook attachments while yielding the same outcome.