No items found.
Blog
June 16, 2025

Prescriptive guidance for automated runbooks: structuring for application tiering and criticality

No one likes to start from scratch - it’s always easier to edit than start with a blank slate. That’s especially true for IT operations processes. The more complex a process, like IT disaster recovery, incident management, or cloud migration, the more important it is to have comprehensive documentation. 

That’s where automated runbooks, templates, and prescriptive guidance come in. They provide the structure and standardization needed for application disaster recovery and other IT operations. This article overviews the importance of prescriptive guidance, its relevance to application criticality, and how automated disaster recovery software can help you recover applications faster.

What is prescriptive guidance in automated runbooks?

Prescriptive guidance is defined as a set of steps and instructions that dictate exactly how processes, like IT operations, should be performed. Automated runbooks outline the step-by-step tasks and dependencies needed to manage IT operations processes including IT disaster recovery, major incident management, cloud migration, or application releases. . When these runbooks are informed by prescriptive guidance, they become even more powerful - enabling consistent, reliable, and compliant execution at scale.

When combined, prescriptive guidance informs or populates automated runbook templates to outline the detailed step-by-step process required for IT operation processes. 

Using prescriptive guidance in automated runbook templates

Populating automated runbook templates with prescriptive guidance helps your teams with: 

  • Standardization and Consistency: Ensures all automated runbooks follow consistent, expert-backed steps, reducing variability and improving reliability across complex IT operations.
  • Accelerated Creation and Deployment: Leverages pre-defined, proven workflows, allowing teams to quickly build and deploy new automated runbooks by focusing on customization rather than starting from scratch. This supports smoother processes across all application tiers.
  • Reduced Human Error and Improved Efficiency: Eliminates manual interpretation and execution, leading to highly consistent, reliable, and optimized task completion, freeing up personnel for strategic work - especially around managing critical applications.

Structuring automated runbook templates by infrastructure and disaster recovery strategy

When structuring automated runbooks, there are two main factors to consider: 

  • Type of infrastructure: on-premises to cloud, availability zone to availability zone, region to region
  • Disaster recovery strategy or pattern: active/active, pilot-light, warm standby, backup, etc. \
Cutover Recover runbook template patterns

Common application recovery and infrastructure patterns

There are commonalities based on the main factors above that impact the tasks, dependencies, milestones, validation tasks, etc. You can structure automated runbook templates based on the recovery and infrastructure pattern to enable a quicker recovery. 

For example, the automated runbook below is for a pilot light recovery - moving from one AWS availability zone (AZ) to another AZ. This runbook was created from a Cutover Recover application recovery template with approximately 80% of the runbook prepopulated using prescriptive guidance, including common tasks, milestones, communications, and validation tasks that typically occur during this type of recovery pattern.

AWS AZ to AZ pilot light disaster recovery: Cutover automated runbook example

How application tiering helps in determining the structure and priority of runbooks

When dealing with large IT estates, it’s important to conduct an application criticality assessment to understand how many applications fall in each application tier. This process, known as application criticality classification, helps provide the organization and prioritization needed during a recovery. 

By clearly defining application criticality tiers, teams can assign appropriate urgency and resources to each runbook. So, when a large-scale IT outage or failure occurs, the runbooks for the most critical services are executed first to expedite recovery.

Examples of common application tiers

Here is a common example of application tiers based on application criticality. 

Tier 0: Mission-critical applications

These are the most important applications, directly impacting the core business operations and revenue generation, and can only handle minimal downtime during a failover. Banking systems, e-commerce platforms, primary healthcare record systems are all examples of mission-critical applications. These systems often require highly detailed, validated automated runbooks informed by prescriptive guidance.

Tier 1: Business-critical applications

Applications that are essential for ongoing business processes but can tolerate some level of downtime during the recovery period. Enterprise resource planning (ERP), customer relationship management (CRM), supply chain and data warehousing systems are all examples of business-critical applications. These still demand prioritised recovery through structured application recovery runbooks.

Tier 2: Business-operational applications

Applications that support daily operations but are less critical than mission-critical or business-critical systems. Common examples include email and office productivity suites, document management systems, non-critical reporting or analytics software and less frequently used collaboration tools. These can be restored after critical applications are stabilised.

Tier 3: Administrative applications

Applications that are primarily used by internal staff for administrative tasks and can tolerate longer downtime. Personal file shares, internal knowledge bases or wikis, test or development environments are all common examples of administrative applications. These are typically lower in application criticality and are recovered later in the process.

Classifying applications into criticality tiers

It’s important for the entire business to align on the classification of applications into criticality tiers. Ideally, this application criticality classification process not only helps determine recovery priorities but will also have an impact on the budget, staffing, and updates for these applications. This exercise should include input from users, managers, network, database, application, and service teams, as well ask, key stakeholders and executive leadership. 

It’s crucial to have complete alignment to ensure that when an IT outage occurs, the business understands which applications are mission-critical and will be recovered first. Many mission-critical applications will have short (< 30 minutes) to near-zero recovery time objectives (RTOs), which require a rapid response. 

Organizing  automated runbooks based on tiers and criticality

Application criticality tiers is a consideration when organizing and prioritizing automated runbooks. Tier 0 and Tier 1 applications often require more intricate highly automated sequences designed for rapid, error-free transitions. These critical applications often rely on detailed prescriptive guidance automated runbooks to meet strict recovery time objectives and ensure minimal disruption.

In contrast, Tier 4 applications would often be simpler, potentially involving more manual steps and focusing on restoring basic functionality. Overall, your automated runbooks could be structured very differently for these tiers, reflecting the vastly different requirements for speed, data integrity, automation complexity or urgency as higher-tier applications. 

The main difference would most likely be the duration of those runbooks, so the tier 4 apps will have tasks that have higher durations in their failover steps for example because the Recovery Time Objectives (RTOs) would be higher, we usually also have more manual tasks in those higher tier runbooks like validation steps that they might not have for the tier zero ones.

Example: Tier 0 automated runbook template

The Tier 0 automated runbook example below includes both manual and automated tasks but leans heavier on the automation side to meet strict application criticality requirements. The automated tasks are connected via the Cutover API or an integration:

  • Task 3: Triggers an Ansible script to start the backend services
  • Task 4: Triggers a Microsoft Azure Pipelines to launch front-end components
  • Task 5: Triggers a Jenkins build to initialize supporting services
  • Task 6: Run a Command Line startup script
  • Task 7: Update DNS records to route traffic to the failover site through TeamCity command line script
Tier 0: Cutover automated runbook example

Example: Tier 4 automated runbook template

The Tier 4 automated runbook example below reflects a lower application tier and includes more manual tasks. It does include two automated tasks:

  • Task 9: Email notifications inform the Tech and Business teams that application start up activities can begin
  • Task 14: Test connection to all databases to ensure they are online and accessible
Tier 4: Cutover automated runbook example

How the Cutover Application Metastore can support tiered and criticality-based structuring for automated runbooks

In addition to integrating third-party applications with our IT disaster recovery solution, you can utilize the automated runbooks and Cutover Application Metastore to accelerate and improve the accuracy of runbook creation and maintenance for IT operations processes. Both Cutover Recover and Cutover Migrate include pre-defined runbook templates, built from our expertise and prescriptive guidance. 

With our Application Metastore, you can auto-generate thousands of tailored runbooks (based on pre-defined templates) with application-specific data, in seconds. This helps ensure that your recovery or migration automated runbooks contain the most up-to-date application data, including configuration management database (CMDB) data to ensure accuracy. The runbook templates auto synchronize to remove potential errors. 

Cutover Application Metastore list of services

In this image, you can view the list of applications, relevant automated runbook templates and other critical application details including:

  • Application criticality tier
  • Service ID
  • Line of business (LOB)
  • Service, LOB, tech, and support owners
  • RTO and RPOs
  • Operational status
  • Service type (On-premises, cloud, etc.)
  • Primary location of application
  • And more

Learn how Cutover runbooks include prescriptive guidance in the pre-defined templates, and how the Cutover Application Metastore can help accelerate and improve runbook creation and accuracy. Book a demo today.

Kimberly Sack
Runbooks
Latest blog posts
Prescriptive guidance for automated runbooks: structuring for application tiering and criticality
Structure automated runbooks using application criticality tiers and built in prescriptive guidance to improve efficiency, reduce risk, and prioritize key operations.
https://cdn.prod.website-files.com/628d0599d1e97aea36c8a467/6850604794f09724137450c2_blog-prescriptive-guide-automated-runbooks.webp
Jun 16, 2025
Jun 16, 2025
Person
Kimberly Sack