# Actions and approvals

> Every change Ace can make, how your action policy decides what needs a person, who can approve, how undo works, how Ace verifies recovery, and how earned autonomy lets an action run automatically.

Source: https://tryace.dev/docs/concepts/actions-and-approvals

Ace can roll back a bad deploy, scale a service, flip a feature flag or open a pull request. Each change is an action with an exact plan, and your action policy decides whether a person approves the plan or Ace runs it on its own.

Every action needs approval by default, and after any change Ace checks that the workload actually recovered.

## How an action works

1. Ace prepares each plan from live state, naming the exact change, the resource it touches, a preflight check, how to undo it (when it can) and the alert that will show it worked.
2. Your policy decides whether the plan waits for approval or runs automatically.
3. A person approves the exact plan on the incident page under **Remediation**, or in Slack. If you choose **Edit values** and change a value, such as the replica count, Ace prepares the plan again and it needs a new approval, because an approval covers only the exact plan.
4. Ace applies the change and confirms it took effect.
5. Ace verifies recovery on the incident's own alerts, then keeps watching in case the problem comes back.

### Where actions come from

- **Undoing a correlated change.** When a deploy, a flag or config change, or an infrastructure change lines up with the incident, Ace proposes undoing it. If a person made that change during or shortly after an incident on the workload, Ace always asks before undoing it, whatever the policy.
- **Operations on running systems**, such as scaling a service or failing over a load balancer, for causes outside code. Ace doesn't propose these on a low-confidence diagnosis, since a live change aimed at the wrong cause can make things worse.
- **Fix pull requests** for code defects, for your team to review.
- **Work after the fix.** Once the workload recovers, Ace can propose redoing lost work, such as redriving an SQS dead-letter queue or replaying failed runs, and these always wait for the fix to deploy.
- **Requests in Slack**, such as `@Ace scale checkout to 6 tasks`. Ace picks the matching operation for the workload, prepares it from live state and posts it for approval, and `@Ace help <workload>` lists what you can ask for there.

### Three kinds of actions

| Kind | What it does | How it runs |
| --- | --- | --- |
| Remediation | Changes the workload to end the incident. | Under your action policy. Judged on recovery. |
| Observability update | Changes only what people see about the incident, such as annotations, silences, downtimes, mutes and issue state. | Automatically by default once allowed on the connection, unless a policy for that exact action says otherwise. Must be undoable. Never judged on recovery. |
| After the fix | Redoes work the incident lost. | Waits for the fix to deploy and always needs approval. Never holds the incident open. |

## Before Ace can act

Ace's access is read-only until an admin allows changes, and each integration has its own switch:

| Integration | How an admin allows actions |
| --- | --- |
| GitHub | The Ace GitHub App opens revert and fix pull requests. **Roll back deploy** and **Redeploy** run through a deploy workflow that an admin confirms for each workload under **Rollback workflow** in **Settings** > **Actions** > **Workloads**. |
| Kubernetes | The Ace connector in your cluster makes changes, only in the namespaces confirmed for the workload. See [Kubernetes](https://tryace.dev/docs/integrations/kubernetes). |
| AWS | An optional actions role with the operation groups you choose. Each group is off until you choose it, and actions run only on the resources an admin confirms for each workload. See [AWS](https://tryace.dev/docs/integrations/aws). |
| Other connected tools | Turn on **Allow Ace to run approved actions** on the connection. For tools whose only writes are observability updates, the switch is **Allow Ace to update this tool during incidents**. Ace never proposes an action that the connection's credentials are known to lack permission for. |

PagerDuty and incident.io have no actions.

## Action policy

An admin sets the policy in **Settings** > **Actions** > **Workloads** by choosing a workload, an action and a mode.

| Mode | In Ace | What happens |
| --- | --- | --- |
| Off | **Off**, "Ace never runs this action." | Ace never runs it, but can still recommend the fix. |
| Approval | **Approval**, "A person approves each plan." | Every plan waits for approval. |
| Approval, tracking eligibility | **Approval** with **Track eligibility** on, "Record whether each proposal would have qualified for Automatic." | Every plan waits for approval, and Ace records whether each one would have qualified for Automatic. This is the default when no policy is set. |
| Automatic | **Automatic**, "Ace acts and posts an Undo option in Slack." | Ace runs qualifying plans on its own after a countdown in Slack. Locked until the action qualifies. See [Earned autonomy](#earned-autonomy). |

### Which policy applies

- **Stop all actions** in **Settings** > **Actions** sets the whole organization to Off, while Ace still investigates and recommends fixes. **Resume actions** turns actions back on.
- If any policy that matches the action is Off, the action doesn't run.
- Otherwise the most specific policy wins. A policy for the exact action beats one for all actions, then a policy for the workload beats one for all workloads, and a policy for the environment beats one for all environments.
- **Change freezes**, in **Settings** > **Actions** > **Change freezes**, are periods such as a launch when nothing runs automatically, though Ace still recommends fixes for approval. You can schedule up to 20.

## Approvals

### Who can approve

| Plan | Who can approve it |
| --- | --- |
| A change to production | An admin, or a member an admin granted approval for that action (or all actions) in that environment (or all environments). |
| Any other plan | Any member. |

In any environment, Ace treats these as production changes:

- every change it makes through Kubernetes, AWS or your other connected tools, except observability updates
- every rollback and redeploy
- every undo of a correlated change

Fix pull requests and changes you report with **I applied it** count as production when the environment is production.

Admins can approve every action in every environment. To choose what a member can approve, use **Settings** > **Team** or set it when you invite them.

### Two approvers

Each plan needs one approver by default. To require **Two people**, add an approval rule in **Settings** > **Actions** > **Approvals**. A rule can cover all actions or one, all workloads or one, and all environments or one, and the most specific rule applies.

The two approvals must come from different people, and the second approver sees **Approve as second**. Actions with two approvers never run automatically, because the rule asks for two people.

### Approving on the web and in Slack

Approve on the incident page under **Remediation** or from the decision card Ace posts in the incident's Slack thread, since both approve the same plan. The Slack decision card has these buttons:

- **Approve**, labeled with the action, such as **Approve rollback** or **Create revert PR**
- **Edit values**
- **Decline**
- Ace's alternatives, as **Instead: …**
- **Something else…**, to tell Ace what you want in your own words

Acting from Slack needs your Slack user linked to your Ace account, because Ace checks your permission when you click. If nobody answers, Ace reminds the thread, and on high and critical incidents it also mentions people who can approve, admins first.

When a fix spans several repositories, its pull requests are approved together in one decision.

## Earned autonomy

Ace earns the right to act on its own one action, workload and environment at a time. **Automatic** stays locked for an action on a workload until the action has a verified track record there, and your policy, preflight checks and daily limits still apply after it unlocks. The workload's action settings show its **Track record**, such as "3 of 5 verified recoveries, 0 worsened", and why Automatic is locked.

### To turn on Automatic

- The policy names one action, one workload and one environment, and the workload's deployment mapping for that environment is confirmed. Automatic can't be set for **All actions** or **All workloads**, because a track record only means something for one action on one workload.
- The action has at least the number of verified recoveries set in **Recoveries required** (5 by default, 1 to 100), with no outcome that made things worse, all in that exact workload, environment and deployment mapping.
- Only recoveries after a deploy that the provider recorded count. A deploy you confirmed with **I deployed it**, or a change you reported with **I applied it**, never counts, since Ace can't verify those itself.
- For **Kubernetes change** (an exact patch), a repair grant replaces the track record. An admin approves the exact fields Ace may change in the confirmed namespaces, with an expiry, under **Settings** > **Data sources** > **Kubernetes**. Only reversible changes to approved values qualify, and creates, deletes, cluster-wide changes, credential fields and list edits always need a person.

If a later outcome makes things worse, the track record stops qualifying and the action goes back to needing approval.

### When an automatic action runs

A plan runs on its own only if Automatic is on and all of these hold. If any one fails, Ace posts the plan for approval with the reason:

- The incident isn't an early warning.
- The action doesn't write to a data store.
- No approval rule asks for two approvers.
- It's inside the policy's set hours (**Limit to set hours**) and outside any change freeze.
- The incident isn't holding its fix for a [linked incident](https://tryace.dev/docs/concepts/how-ace-works).
- The preflight is safe. A blocked preflight never runs, and one with cautions runs only if **Run despite preflight cautions** is on.
- The action doesn't always need a person. See the [catalog](#action-catalog).
- For Kubernetes, no GitOps controller (Argo CD or Flux) manages the object, since the controller would revert the change. The operation also isn't one that always needs a person, such as an image from a registry the workload doesn't already use.
- For everything else, Ace tied the incident to a specific deployment, unless **Run without a linked deployment** is on.
- The plan can be undone.
- The action is under its **Daily limit** (5 by default, up to 100, counted per UTC day).

AWS plans always carry a preflight caution, so AWS actions run automatically only with **Run despite preflight cautions** on.

Before an automatic action runs, Ace posts a short countdown with an **Undo** option in the incident's Slack thread. If the countdown can't be posted, the action doesn't run, because nobody would have the chance to stop it.

For **Fix pull request** and **Revert pull request**, you can turn on **Auto-merge pull requests**, which is off by default. With it on, Ace merges when every Ace reviewer passes and checks are green, after announcing the merge in Slack so anyone can stop it.

## Undo and rollback

Undo exists only where Ace can restore the exact prior state, and the catalog shows which actions have it.

- Before an automatic action runs, **Undo** in the Slack countdown cancels it.
- After an action is applied, undo is a new action that Ace prepares from the prior state, and it needs approval like any other.
- Observability updates are undone with one click on the incident. The click is your approval.

When a change makes things worse, Ace can propose undoing it but never undoes it automatically.

**Roll back deploy** redeploys a known-healthy revision through the deploy workflow an admin confirmed for the workload, without reversing database changes or provisioning infrastructure. A rollback can include the matching revert pull request in the same approval, so your main branch matches what's running.

## Recovery verification

Ace first confirms the action took effect, then checks the alerts that opened the incident, such as the original HTTP check, the same alert from your tool, or the metric's normal range. Passing CI, a merged pull request or someone closing the incident never counts, because none of them show the workload is healthy. See [How Ace works](https://tryace.dev/docs/concepts/how-ace-works).

| Result | In Ace | What it means | Counts toward Automatic |
| --- | --- | --- | --- |
| Verified recovered | **Recovered** | The incident's alerts recovered after the change took effect. | Yes, when the provider recorded the deploy |
| Did not recover | **Did not recover** | The change took effect, but the alerts didn't recover. | No |
| Made it worse | **Made it worse** | The alerts got worse after the change. | Blocks Automatic for that action on that scope |
| Recovered on its own | **Recovered on its own** | The workload recovered before the change took effect, or after some other change. | No |

After recovery, Ace keeps watching in case the problem returns. Results feed [memory](https://tryace.dev/docs/concepts/memory), so a fix that made an incident worse on a workload is never proposed again there, and a fix that didn't recover it is proposed again only with new evidence.

## Action catalog

Each operation below is a separate action with its own policy and track record, named as Ace shows it.

- **Always a person** means it never runs automatically, whatever the policy. "Yes (data store)" marks a write to a data store.
- **Undo** means Ace can restore the exact prior state.
- Values you can edit before approving, such as a replica count, show their allowed range.

### GitHub and deploys

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| Fix pull request | Opens a pull request with a fix for a code, config or infrastructure-as-code cause. | No | Yes |
| Revert pull request | Opens a pull request that reverts the change behind the incident. | No | Yes |
| Roll back deploy | Redeploys a known-healthy revision through your confirmed deploy workflow. | No | Yes |
| Redeploy | Deploys the revision already serving again, with no code change. | No | No |
| Applied by a person | Records a change you made yourself (**I applied it**). Ace runs nothing and only verifies recovery. | Yes | No |

### Kubernetes

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| Kubernetes change | An exact patch, create or delete on a namespaced resource. Automatic only with a repair grant. | No | No |
| Kubernetes rollout restart | Restarts a Deployment, StatefulSet or DaemonSet's pods. | No | No |
| Kubernetes scale | Sets replicas on a Deployment or StatefulSet (0–1,000). | No | Yes |
| Kubernetes autoscaler update | Changes an autoscaler's minimum and maximum replicas (1–1,000) or CPU target (1–1,000%). | No | Yes |
| Kubernetes rollout undo | Restores a previous revision. | No | Yes |
| Kubernetes rollout pause | Pauses a Deployment's rollout. | No | Yes |
| Kubernetes rollout resume | Resumes a paused Deployment rollout. | No | Yes |
| Kubernetes container image | Sets a container's image, pinned by digest. | No | Yes |
| Kubernetes container resources | Changes a container's CPU and memory requests and limits. | No | Yes |
| Kubernetes environment value | Sets a non-secret environment variable on a container. | Yes | No |
| Kubernetes CronJob suspend | Suspends a CronJob. | No | Yes |
| Kubernetes CronJob resume | Resumes a suspended CronJob. | Yes | Yes |
| Kubernetes Job re-run | Runs a Job, or a CronJob's job, again. | Yes | No |
| Kubernetes disruption budget | Changes a PodDisruptionBudget. | No | Yes |
| Kubernetes node cordon | Stops new pods from scheduling on a node. | Yes | Yes |
| Kubernetes node uncordon | Lets pods schedule on a node again. | Yes | Yes |
| Kubernetes node taint | Adds a taint to a node. | Yes | Yes |
| Kubernetes node taint removal | Removes a taint from a node. | Yes | Yes |
| Kubernetes pod delete | Deletes a pod so its controller replaces it. | Yes | No |
| Kubernetes node drain | Cordons a node and evicts the confirmed namespaces' pods, respecting disruption budgets. Undo only uncordons. | Yes | No |
| Argo Rollouts abort | Aborts an Argo Rollout. | No | Yes |
| Argo Rollouts promote | Promotes an Argo Rollout. | Yes | No |
| Argo Rollouts retry | Retries an aborted Argo Rollout. | Yes | Yes |
| Argo Rollouts undo | Restores an Argo Rollout's previous revision. | No | Yes |
| Argo CD sync | Syncs an Argo CD application to what Git holds now. | Yes | No |
| Argo CD rollback | Rolls an Argo CD application back to an earlier history entry. Needs auto-sync off. | No | Yes |
| Argo CD auto-sync disable | Turns off auto-sync for an application. | Yes | Yes |
| Argo CD auto-sync enable | Turns on auto-sync for an application. | Yes | Yes |
| Flux suspend | Suspends a Flux Kustomization or HelmRelease. | Yes | Yes |
| Flux resume | Resumes a Flux Kustomization or HelmRelease. | Yes | Yes |
| Flux reconcile | Asks Flux to reconcile a Kustomization or HelmRelease now. | No | No |

Any Kubernetes change to an object a GitOps controller manages always needs a person.

### AWS

Each AWS action belongs to an operation group that you turn on in the actions role, and all of them run only on resources confirmed for the workload.

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| ECS service rollback | Returns an ECS service to its previous task definition. | No | Yes |
| ECS service restart | Forces a new deployment of an ECS service. | No | No |
| ECS desired task count | Sets a service's desired tasks (0–5,000). | No | Yes |
| ECS task stop | Stops one ECS task so the service replaces it. | No | No |
| ECS auto scaling limits | Changes a service's scaling minimum and maximum (0–5,000). | No | Yes |
| ECS task size | Changes a task's CPU (128–16,384 units) and memory (512–122,880 MiB). | Yes | Yes |
| Lambda provisioned concurrency scaling limits | Changes provisioned-concurrency scaling limits (0–10,000). | No | Yes |
| Lambda alias rollback | Points an alias back to its previous version. | No | Yes |
| Lambda alias weighted routing | Shifts traffic between alias versions (weight 0–1). | No | Yes |
| Lambda reserved concurrency | Sets reserved concurrency (0–10,000). | No | Yes |
| Lambda provisioned concurrency | Sets provisioned concurrency (1–10,000). | No | Yes |
| Lambda event source mapping enable/disable | Turns an event source mapping on or off. | No | Yes |
| Lambda event source batch size | Changes an event source's batch size (1–10,000). | No | Yes |
| Lambda memory and timeout | Changes a function's memory (128–10,240 MB) and timeout (1–900 s). | No | Yes |
| Auto Scaling group desired capacity | Sets desired instances (0–10,000). | No | Yes |
| Auto Scaling group size limits | Changes a group's minimum and maximum size (0–10,000). | No | Yes |
| Auto Scaling process suspension | Suspends Auto Scaling processes. | No | Yes |
| Auto Scaling process resumption | Resumes suspended processes. | No | Yes |
| Auto Scaling instance refresh | Starts an instance refresh (minimum healthy 0–100%). | Yes | No |
| Auto Scaling instance refresh cancellation | Cancels a running instance refresh. | No | No |
| Auto Scaling instance refresh rollback | Rolls back a running instance refresh. | No | No |
| Auto Scaling instance health | Marks an instance unhealthy so the group replaces it. | No | No |
| Auto Scaling instance termination | Terminates one instance in a group. | No | No |
| Auto Scaling group instance type | Changes a group's instance type. | Yes | Yes |
| EC2 instance reboot | Reboots an instance. | No | No |
| EC2 instance stop | Stops an instance. | Yes | Yes |
| EC2 instance start | Starts a stopped instance. | Yes | Yes |
| EC2 instance type | Changes an instance's type. | Yes | Yes |
| EKS managed node group scaling | Changes a node group's minimum, maximum and desired size (0–1,000). | No | Yes |
| RDS instance reboot | Reboots a database instance. | Yes (data store) | No |
| Aurora cluster failover | Fails an Aurora cluster over to a replica. | Yes (data store) | No |
| RDS instance class | Changes a database instance's class. | Yes | Yes |
| RDS parameter | Changes a database parameter. | Yes (data store) | Yes |
| Aurora reader added | Adds a reader to an Aurora cluster. | Yes (data store) | Yes |
| Aurora reader removed | Removes a reader from an Aurora cluster. | Yes | Yes |
| Aurora Serverless v2 capacity | Changes minimum and maximum capacity (0–256 ACU). | Yes (data store) | Yes |
| RDS storage and autoscaling limit | Grows storage and changes its autoscaling limit (20–65,536 GiB). | Yes (data store) | Yes |
| RDS Proxy connection pool | Changes the proxy's connection limits (1–100%). | Yes (data store) | Yes |
| DynamoDB provisioned capacity | Changes read and write capacity (1–40,000 units). | Yes (data store) | Yes |
| DynamoDB auto scaling limits | Changes a table's scaling limits (0–40,000 capacity units). | Yes (data store) | Yes |
| DynamoDB capacity mode | Switches between provisioned and on-demand capacity. | Yes | Yes |
| ElastiCache node reboot | Reboots cache nodes. | Yes (data store) | No |
| ElastiCache replica count | Changes replicas per shard (0–5). | Yes (data store) | Yes |
| ElastiCache node type | Changes the node type. | Yes | Yes |
| ElastiCache failover | Fails a replication group over. | Yes | No |
| SQS dead-letter queue redrive | After the fix: moves messages from the dead-letter queue back to the source queue (1–500 messages per second). | Yes (data store) | No |
| SQS visibility timeout | Changes the visibility timeout (0–43,200 s). | No | Yes |
| SQS maximum receives | Changes receives before dead-lettering (1–1,000). | No | Yes |
| Kinesis shard count | Changes a stream's shards (1–10,000). | No | Yes |
| Target group health check | Changes a target group's health check. | No | Yes |
| Target group deregistration delay | Changes the deregistration delay (0–3,600 s). | No | Yes |
| Load balancer target removal | Removes a target from a target group. | No | Yes |
| Load balancer target registration | Adds a target to a target group. | No | Yes |
| Load balancer traffic shift | Changes a listener's weights between target groups. | No | Yes |
| Route 53 weighted record | Changes a weighted record's weight (0–255). | No | Yes |
| Route 53 failover swap | Swaps primary and secondary failover records. | Yes | Yes |
| CloudFront invalidation | Invalidates cached paths. | No | No |
| API Gateway stage throttling | Changes a stage's rate (0–100,000 per second) and burst (0–100,000). | No | Yes |
| API Gateway canary promotion | Promotes a stage's canary. Only a person proposes it. | No | No |
| API Gateway canary rollback | Rolls back a stage's canary. | No | No |
| WAF IP set addition | Adds addresses to a WAF IP set. | No | Yes |
| WAF IP set removal | Removes addresses from a WAF IP set. | No | Yes |
| WAF rule action override | Overrides a WAF rule's action. | No | Yes |
| CodeDeploy stop and roll back | Stops a deployment and rolls it back. | No | No |
| CloudFormation update cancellation | Cancels a stack update in progress. | No | No |
| CloudFormation rollback continuation | Continues a stack's stuck rollback. | No | No |
| AppConfig deployment stop | Stops an AppConfig deployment. | No | No |
| Step Functions execution redrive | After the fix: redrives a failed execution. | No | No |
| EventBridge rule disable | Disables an EventBridge rule. | No | Yes |
| EventBridge rule enable | Enables an EventBridge rule. | No | Yes |
| SSM Automation runbook | Runs an SSM Automation document an admin allowed. | Yes | No |
| SSM Run Command | Runs an SSM command on instances. | Yes | No |
| CloudWatch alarm actions muted | Observability update: mutes a firing alarm's actions during an approved fix. Runs on its own. | No | Yes |
| CloudWatch alarm actions restored | Observability update: restores an alarm's actions. | No | Yes |

### Vercel

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| Vercel instant rollback | Rolls production back to an earlier deployment. | No | Yes |
| Vercel promotion | Promotes a deployment to production. | No | Yes |
| Vercel redeploy | Rebuilds and redeploys a deployment. | No | Yes |
| Vercel deployment cancel | Cancels a deployment that's still building. | No | No |
| Vercel rolling release stage approval | Moves a rolling release to its next stage. | Yes | No |
| Vercel rolling release abort | Aborts a rolling release. | No | No |
| Vercel Attack Challenge Mode | Turns on Attack Challenge Mode for 15–1,440 minutes. | Yes | Yes |
| Vercel firewall IP block | Blocks an IP address. | Yes | Yes |
| Vercel firewall IP unblock | Removes an IP block. | Yes | Yes |
| Vercel environment variable change | Sets an environment variable to a new value you give, then redeploys. | Yes | Yes |

### Cloudflare

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| Cloudflare cache purge | Purges cached content for a zone. | No | No |
| Cloudflare Worker rollback | Rolls a Worker back to an earlier version. | No | Yes |
| Cloudflare load balancer failover | Turns a load balancer pool off or on to move traffic. | Yes | Yes |
| Cloudflare security level | Changes a zone's security level. | Yes | Yes |
| Cloudflare WAF rule toggle | Turns a WAF rule on or off. | Yes | Yes |

### Feature flags

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| LaunchDarkly flag kill switch | Turns a flag off or on. | No | Yes |
| LaunchDarkly percent rollout | Changes a flag's rollout percentage in stages. | No | Yes |
| LaunchDarkly flag version restore | Restores a flag to its state before a recorded change. | No | Yes |
| PostHog flag rollout | Changes a flag's rollout percentage in stages. | No | Yes |
| PostHog flag switch | Turns a flag off or on. | No | Yes |

### Background jobs

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| Trigger.dev run replay | After the fix: replays failed runs in stages (up to 1–2,000 runs). | No | No |
| Trigger.dev run cancel | Cancels runs in stages (up to 1–2,000 runs). | Yes | No |
| Trigger.dev queue pause | Pauses a task's queue. | Yes | Yes |
| Inngest run rerun | After the fix: reruns failed runs in stages (up to 1–500 runs). | No | No |
| Inngest function pause | Pauses a function. | Yes | Yes |
| Inngest function resume | Resumes a paused function. | Yes | Yes |
| Inngest run cancel | Cancels runs in stages (up to 1–500 runs). | Yes | No |

### Databases

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| PlanetScale schema change | Deploys a schema change through a deploy request. | Yes | Yes |
| PlanetScale schema revert | Reverts a deployed schema change. | Yes | No |
| PlanetScale backfill | Updates rows in batches (1–1,000 rows per batch, up to 100,000 rows) in stages. | Yes | No |
| Supabase pooler pool size | Changes the default pool size (1–3,000 connections). | Yes | Yes |
| Supabase read-only mode lift | Lifts read-only mode on a project. | Yes | No |
| Supabase disk increase | Grows the project's disk (1–60,000 GB). | Yes | No |
| Supabase project restart | Restarts the project. | Yes | No |

All PlanetScale and Supabase actions write to a data store.

### LiteLLM

| Action | What it does | Always a person | Undo |
| --- | --- | --- | --- |
| LiteLLM model fallback | Routes a failing model to a fallback. | No | Yes |
| LiteLLM budget and limits | Changes budgets and rate limits. | Yes | Yes |

### Observability updates

These change only what your team sees, so once you allow them on the connection, the ones that can be undone run on their own during incidents.

| Action | What it does | Undo |
| --- | --- | --- |
| Grafana annotation | Marks the incident on a Grafana dashboard. | Yes |
| Grafana annotation removal | Removes that annotation. | No |
| Grafana alert silence | Silences a Grafana alert for 5–240 minutes. | Yes |
| Grafana silence expiry | Ends a silence early. | No |
| Axiom annotation | Marks the incident on an Axiom dataset. | Yes |
| Axiom annotation removal | Removes that annotation. | No |
| Sentry issue resolve | Resolves a Sentry issue. | Yes |
| Sentry issue reopen | Reopens a Sentry issue. | No |
| Sentry issue assignment | Assigns a Sentry issue. | Yes |
| Datadog monitor downtime | Silences a Datadog monitor for 5–240 minutes. | Yes |
| Datadog downtime cancellation | Ends a downtime early. | No |
| New Relic muting rule | Mutes a New Relic alert for 5–240 minutes. | Yes |
| New Relic muting rule removal | Removes a muting rule. | No |
| Honeycomb marker | Marks the incident on a Honeycomb dataset. | Yes |
| Honeycomb marker removal | Removes that marker. | No |

Staged actions, such as rollouts, replays, cancels and backfills, check the incident's alert between stages. You can change **Wait between stages** (60–3,600 seconds) before you approve.

## Next steps

  - [How Ace works](https://tryace.dev/docs/concepts/how-ace-works): Where actions fit in an incident, from first signal to close.
  - [Operating rules](https://tryace.dev/docs/concepts/operating-rules): Tell Ace how your team wants fixes done.
  - [Roles and permissions](https://tryace.dev/docs/security/roles-and-permissions): What admins and members can do.
  - [How memory works](https://tryace.dev/docs/concepts/memory): How verified results shape future fixes.