> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Recommend response

Diagnosis has established what changed and how bad it is on the incident record. Those assessments keep updating as evidence arrives. From here, two questions drive the response:

  1. What are the potential response options?
  2. Which option should we choose?

Teams set automation eligibility in advance: which action types are in play at a given confidence and impact level, and which require human approval before they run. Scoring and ranking happen inside that boundary, whether a person picks from the list or an agent proposes options within guardrails.

Port scores and ranks eligible response options on the incident record and explains the tradeoffs behind each rank. Options that need approval wait for a human before execution.

The problem: Under pressure, teams either jump on the first plausible action or debate options with no shared criteria. Neither leaves a record of why a choice was made.

The solution: Apply automation eligibility to narrow the candidate list, score each remaining option on the four criteria below, and present a ranked set with the tradeoffs spelled out.

Recommend response: automation eligibility filters the candidate set, then options are scored and ranked on effectiveness, risk, reversibility, and time to verify

Automation eligibility​

Before scoring, automation eligibility uses current confidence and impact on the record to decide which action types are in bounds. Most teams express that as a tiered ladder:

  1. Read-only actions - investigate and correlate; always in bounds.
  2. Containment actions - pause, isolate, or throttle; in bounds even at lower confidence and early-stage impact.
  3. Reversible corrective actions - rollback, restart, or scale; in bounds once confidence and impact justify it.
  4. Actions requiring sign-off - high blast radius or changes you cannot undo; may appear on the ranked list but need human approval before execution.

How options get scored​

Every candidate gets scored on the same four criteria:

1. Effectiveness​

How likely is this action to address the diagnosed cause? Effectiveness draws on causal confidence from diagnosis, whether similar actions worked on similar failures before, and whether the action targets the cause rather than a symptom. An action that does not align with what is actually wrong scores low here, even when it is safe and fast to execute.

2. Risk​

What could this action break on its own? Risk rises with how broad the change is and how deep it reaches into dependencies. A narrow, shallow action carries less risk than a broad one, even if both aim at the same cause.

3. Reversibility​

How easily can you back out if you are wrong? Trying something is not the same as being able to undo it. Rollback automation, how deep the state change goes, and whether data stays safe determine how cleanly you can reverse course.

4. Time to verify​

How soon will you know whether it worked? An action that would fix the problem in theory does not help if it takes an hour to confirm. Time to verify accounts for propagation time, confirmation time, and whether a human approval step sits in the critical path.

Next: once a response is chosen, it has to run inside boundaries the system enforces. See Act on response.

Back to the self-healing incidents overview.