Runbook Audit Logs



This feature is only available for Enterprise customers. If you would like to enable the Runbook Audit Log endpoint, please reach out to your Customer Success Manager to activate.

Maintaining Runbook definitions for your incident response is crucial. We developed a Runbook Audit Log endpoint so you can check on changes or programmatically set checks to see if an important Runbook is edited. This allows you to go back and fix unwanted changes or store history for change management purposes.

We also have a Terraform integration so you can track FireHydrant configuration as code, and this will enable tracking FireHydrant changes via Git.

Getting started

Once this endpoint is enabled for your organization, we begin storing Runbook Audit Logs from when it is turned on.

To get started, you must first set up an API key to access this endpoint. Read about creating API keys here.

If you would like to further reference our API docs for this endpoint, please visit our developer documentation here.

Logs Available

This Runbook endpoint includes information about the creation, update, and deletion of a Runbook or a Runbook Step. It does not currently include details about changes to the rules or conditions of the step.

With the example payload below, changes to the Runbook would show under audited changes. Referencing the example payload below, “id” & “action” can help determine if a specific Runbook was created, updated, or deleted. Additionally, we provide other key identifiers on who has changed or created this Runbook for tracking purposes via the field [‘user_id’].

Over time, this information can be queried to look back and change Runbooks to their previous states.

  "id": 2,
  "account_id": 1,
  "auditable_id": "84edbbc2-b15c-4d18-94aa-c72073159a74",
  "auditable_type": "Runbooks::Step",
  "user_id": "0d2e8479-c00b-44c7-bca4-01e60a3e8035",
  "user_type": "User",
  "action": "create",
  "audited_changes": {
    "name": "Assign A Role",
    "config": {
      "role": {
        "label": "Commander",
        "value": "2e0f57b8-57a6-4fce-b471-10adfcbe2bf6"
      "user": {
        "label": "Incident Opener",
        "value": "{\"type\":\"incident_opener\"}"
    "repeats": false,
    "position": 0,
    "action_id": "95facc8b-be6f-4d71-90af-f13c53126de6",
    "automatic": true,
    "account_id": 1,
    "repeats_at": null,
    "runbook_id": "69e62138-e673-4c21-b4fb-caf775308acc",
    "discarded_at": null,
    "execution_id": null,
    "delay_duration": "PT0S",
    "derived_from_id": null,
    "repeats_duration": null
  "version": 1,
  "created_at": "2022-04-26T19:34:32.889Z"  

Use Cases

This endpoint can help organizations protect Runbook stages and enforce secure and consistent incident management policies. Here are a few suggestions for how to incorporate this endpoint into your organization's processes:

  1. Revert changes: Query this endpoint specifically on a Runbook to see past changes. Past information on changes can be used to re-inject back into a Runbook if you would like to return to a previous state if the new change is no longer unwanted.

  2. Alert on changes: Set up a recurring webhook to send a GET to the /runbook_audits endpoint for new changes across your Runbooks. A middleware can be established to check for the most recent change via the timestamp on the Runbook change. From here, you can customize how to alert on changes based on your organization's needs.