Cookie consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

RTO/RTA

Last updated: May 6th, 2025

Problem Statement

Preparing for Disaster Recovery (DR) procedures brings complexity. It's important to have disaster recovery metrics and strategies in place to measure and improve disaster readiness. Two of the most important disaster recovery metrics include RTO and RTA.

Solution

What does RTO and RTA actually mean? RTO is the period of time that is defined by an organisation to restore an affected service. RTA is the actual time taken to restore a service or perform data recovery. The Cutover API has the capability for you to calculate both. While Cutover is not a reporting tool, the RTO and RTA can be calculated to provide greater visibility to your internal stakeholders.

Key Benefits

  • Create bespoke dashboards or reports based on Cutover data
  • Amalgamate critical runbook data with stakeholder dashboards

Recipe

Our customers have specific internal and external reporting needs, and Cutover has many dashboards that provide critical real-time data. With our extensive Cutover API, customers can seamlessly extract their Cutover data and build reports using their preferred reporting tools. A great example of this in action is the RTO/RTA report. The Cutover API can be utilised to:

  • Configure the RTO value by setting an integer.
  • Configure the RTO value by referencing a searchable custom field.
  • Retrieve both your RTO and RTA values to report on.

Configure the RTO value by setting an integer.

Note: Before setting the RTO value, ensure the runbook template is in a draft state.

1. Execute the update on a runbook in your recovery template, making sure to include the runbook ID in the request.

A PATCH request will be necessary, and the URL will be formatted like this:

/core/runbooks/{id}

The request body will appear as follows:

{
	"data": {
		"type": "runbook",
		"attributes": {
			"rto": 3600
		},
		"relationships": {
			"rto_start_task": {
				"data": {
					"id": "1",
					"type": "task"
				}
			},
			"rto_end_task": {
				"data": {
					"id": "5",
					"type": "task"
				}
			}
		}
	}
}

The request body above requires the "rto" attribute to be set as an integer and represented in seconds.

  • "rto": 3600 

The RTO attribute is set to 3600 seconds, which equals 1 hour. Additionally, both the RTO start and end tasks are required. The time elapsed between these two tasks during a live execution will be used to calculate the RTA. The RTA value will then determine whether the RTO was successfully met.

2. In the Cutover template, we can now see the API has successfully updated the RTO, RTO start task and RTO finish task.

Configure the RTO value by referencing a Searchable Custom Field.

Note: Before setting the RTO value, ensure that the runbook template is in a draft state.

The API can be used to reference a dependent field value from a searchable custom field to set the RTO. For instance, Cutover can recognize the rto: 30 minutes dependent field value and set this as the RTO for the runbook template, as demonstrated below:

This can be achieved by following the steps below:

1. Retrieve the Searchable Custom field ID and its dependent value using the List Custom fields endpoint.

Using the example in the screenshot above:

  • ‘Service from CMDB’ is a searchable custom field and its ID = 1305.
  • ‘rto’ is the dependent field value and its ID =1308.

The dependent field value 'rto' ID must be stored in your script, as it will be used to set the RTO for the runbook template in step 3.

2. Execute the update on a runbook in your recovery template, making sure to include the runbook ID in the request.

A PATCH request will be necessary, and the URL will be formatted like this:

/core/runbooks/{id}

The request body will appear as follows:

{
	"data": {
		"type": "runbook",
		"attributes": {
			"custom_field_values": [{
				"name": "Service from CMDB",
				"value": "Japan Datacentre"
			}]
		}
    }
}

The request body above will configure the searchable custom field using the custom_field_values attribute. This searchable custom field must be set on the runbook before the rto_source can be added.

The runbook will now show the searchable custom field as illustrated below:

3. Execute the update on a runbook in your recovery template, making sure to include the runbook ID in the request. A PATCH request will be necessary, and the URL will be formatted like this:

/core/runbooks/{id}

The request body will appear as follows:

{
	"data": {
		"type": "runbook",
		"attributes": {
		},
		"relationships": {
			"rto_source": {
				"data": {
					"id": "1308",
					"type": "custom_field"
				}
			},
			"rto_start_task": {
				"data": {
					"id": "1",
					"type": "task"
				}
			},
			"rto_end_task": {
				"data": {
					"id": "4",
					"type": "task"
				}
			}
		}
	}
}

The runbook will now be updated according as shown below:

Retrieve your RTO and RTA values using the API

After completing your recovery runbook, you can use our API to fetch the RTO and RTA values. These can then be stored in your preferred reporting tools or CMDB. Follow the steps below to do so:

1. Execute the Get a Runbook API call making sure to include the runbook ID in the request.

A GET request will be necessary, and the URL will be formatted like this:

/core/runbooks/{id}

2. From the API response you will be able to extract the necessary RTO and RTA details as shown below:

 "meta": {
      "tasks_count": 5,
      "completed_tasks_count": 5,
      "rto_rta_metrics": {
        "rto": null,
        "rto_source_name": "CMDB Service:: rto",
        "rto_source_value": "30 minutes",
        "rto_computed": 1800,
        "rta": null,
        "rta_diff": null
      }
    }
  }

The definitions of each attribute can be found in the schema section of the Get a Runbook page. 


Available endpoints