The research team at DORA (DevOps Research and Assessment) has touched the backbone of operations metrics. The "Mean Time to Recovery" (MTTR), that metric that has been haunting us in dashboards for a decade, has just officially split into two: Human-MTTR and Agent-MTTR.

The announcement on the Google Cloud DevOps blog doesn't surprise me. I've spent months seeing how on-call teams spend more time supervising AIs fixing things than fixing them themselves. Measuring both resolutions under the same MTTR umbrella was falsifying the data. An agent repairs a downed cluster in milliseconds. A human needs to drink coffee, read logs, and understand the context. Mixing those arithmetic means destroyed any serious performance analysis.

If your system raises a ticket, an agent analyzes it, restarts a pod in Kubernetes, and closes the incident in ten seconds, your overall MTTR plummets. You look like a reliability genius. But if a critical failure requires manual intervention and you take four hours, that data is masked by the machine's speed on minor bugs.

DORA now forces us to separate these two realities. Companies must report what percentage of their critical incidents are resolved exclusively by AI versus humans.

The impact on on-call and data engineering

This separation changes the game for AI governance in production. It's no longer enough to say the platform is stable. You have to prove how much of that stability is autonomous and how much depends on burning out your engineers at three in the morning.

In practice, this requires modifying our observability pipelines. You can't calculate Agent-MTTR if your ticketing system (Jira, PagerDuty, Opsgenie, Service Now...) doesn't differentiate between a human resolution and an automated closure by an AI agent. We already explored how to integrate AI agents into incident management, but now tracking their activity becomes mandatory at the executive level.

How to implement the separation in production

Let's ground this. If you work handling systems telemetry data, you need to intercept incident resolution webhooks and add metadata. You have to inject a classification layer before that data ends up in your Data Warehouse to calculate the new DORA dashboard.

Here's an example of how you can parse a PagerDuty payload using Python in a Lambda or Cloud Run function to derive the origin of the resolution. The idea is simple: if the user resolving the incident is a bot or a service account designated as an agent, we tag the metric accordingly before sending it to Prometheus or Datadog.

import json
from datetime import datetime

# List of user IDs that are AI agents in our system
AGENT_USER_IDS = ["USR-AI-01", "USR-AI-02", "AUTORESOLVER-BOT"]

def procesar_webhook_incidencia(event, context):
    payload = json.loads(event['body'])

    # We only care about resolved incidents
    if payload.get('event') != 'incident.resolved':
        return {"statusCode": 200, "body": "Ignored - Not a resolution"}

    incident = payload['incident']
    resolved_by = incident['resolved_by']['id']

    # Extract times
    created_at = datetime.fromisoformat(incident['created_at'].replace('Z', '+00:00'))
    resolved_at = datetime.fromisoformat(incident['resolved_at'].replace('Z', '+00:00'))
    time_to_resolve_seconds = (resolved_at - created_at).total_seconds()

    # DORA Classification
    is_agent = resolved_by in AGENT_USER_IDS
    metric_name = "dora_agent_mttr" if is_agent else "dora_human_mttr"

    # Send metric to our observability backend (e.g. Datadog)
    enviar_metrica_datadog(
        metric_name=metric_name,
        value=time_to_resolve_seconds,
        tags=[f"service:{incident['service']['name']}", f"severity:{incident['urgency']}"]
    )

    return {"statusCode": 200, "body": f"Registered as {metric_name}"}

def enviar_metrica_datadog(metric_name, value, tags):
    # Datadog API sending simulation
    print(f"[{metric_name}] Value: {value}s | Tags: {tags}")

With a script like this hooked into your flows, you start separating the metric immediately. You have a time series for human effort and another for raw machine performance.

We will soon see native tools adapting to this, but in the meantime, it's on us to get our hands dirty at the data level. If you are building teams of agents to automate infrastructure, separating the MTTR is the first logical step to justify the investment without manipulating the numbers.