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 api-server.

You could set this explicitly on the 2nd Runbook, like so:

• The caveat is that the generic SEV1 Runbook 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 api-server Runbook.

• This is an example of Runbook layering and offers advantages in keeping your Runbooks and automations organized.
• We know that the api-server Runbook 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 SEV1 process. You'll enter just a single top-level SEV1 Runbook, 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.