Auto-remediation

Operations → Auto-Remediation (/gravity/operations/auto-remediation) lets you turn a recognizable incident into an automatic response, instead of triaging the same alert by hand every time it recurs. Creating, editing and deleting rules requires the Admin or Owner role.

Binding a pattern to a runbook

A rule has:

Name
Incident pattern - a regular expression or plain keyword, matched (case-insensitively) against a new incident’s title and dedup key
Runbook - which runbook to trigger on a match
Confidence threshold - how closely the pattern has to match before the rule fires (an exact match scores higher than a loose keyword match)
Cooldown (minutes) - the minimum time between two triggers of the same rule, independent of the runbook’s own cooldown
Auto-approve or manual review - see Safety rails below
Severity threshold (info, warning, error or critical)
Enabled

Use Test Pattern in the rule form to check a candidate pattern against a sample incident title before saving - it scores the match the same way the live evaluation does, entirely in your browser, without creating anything.

When rules run

Every enabled rule for your organization is evaluated automatically each time a new incident is created - this always runs, with no separate switch to turn it on. If an incident matches a rule at or above its confidence threshold and the rule isn’t in cooldown, the rule fires.

Safety rails

Cooldown prevents a rule from firing again for the same condition within its configured window, even if the pattern keeps matching.
Auto-approve off (the default) - a match creates a change request for human review instead of running the runbook immediately. You’ll find it in Change requests, pre-filled with which rule and incident triggered it.
Auto-approve on - the runbook is triggered immediately when the rule matches, with no human step in between. Turning this on is a real decision: it means an automated pattern match can execute an action against a live host unattended. Whether a triggered runbook actually reaches a host still depends on fleet dispatch being enabled for your environment - where it isn’t, the run is recorded as failed rather than reaching the agent; see the caution in Runbooks. Start with manual review until you’re confident the pattern is accurate, and only switch to auto-approve once you trust it.

Editing, enabling and deleting

The pencil on a rule’s row opens the same form as Add Rule, prefilled, with the same fields; saving updates the rule. The trash icon deletes the rule after a confirmation that names it. If the backend refuses a change, its message is shown as received.

Each rule also has an Enabled toggle in the rules table - turning it off stops the rule from being evaluated without deleting its configuration, useful while you’re still tuning a pattern.

Reviewing what fired

The Recent Triggers list at the bottom of the page shows the last 10 times a rule matched an incident for your organization, so you can confirm a rule is behaving as expected (or catch one that’s firing more than you intended).

Severity threshold, fire count and last fired

The rules table also shows each rule’s severity threshold, fire count and when it last fired. This page is also where the former Auto-Triggers screen now lives - the two screens edited the same rules, so /gravity/operations/auto-triggers (and the old alert-runbooks address) redirect here. A banner on the page has the caveat that matters: the severity threshold, fire count and last fired are driven by automatic triggering, which has to be enabled for your environment before a rule can fire on them, so don’t rely on a rule’s severity threshold being enforced unless your account team has confirmed it is.

What’s next

Runbooks - what actually runs when a rule fires
Incidents - the source of the patterns you’re matching against
Change requests - where manually-reviewed matches land
Audit log - every rule match and trigger is recorded there