# Ace AI: an outage shouldn't stop your whole team

> Your engineers should be building great things, not fixing outages or running cloud ops. Ace is a team of AI agents that investigates production incidents across your infrastructure, telemetry and code, prepares the fix as a reviewable pull request and checks that service has recovered.

Ace is built and operated by [Vratix, Inc.](https://vratix.com), whose SOC 2 Type II report covers Ace.

## At a glance

- **What it does:** investigates incidents, connects evidence across tools, proposes and prepares fixes, verifies recovery and remembers what it learned.
- **Who it is for:** engineering teams that run production services on AWS and want fewer engineer hours spent on incident work.
- **Agents:** Telemetry, Infrastructure, Code and Recovery agents work the same case and share findings with each other.
- **Starts from:** Alertmanager alerts, Amazon SNS notifications such as CloudWatch alarms, Sentry, Grafana and PostHog alerts, failed Trigger.dev runs, Ace's own HTTP health checks, or a request in the app or Slack. An alert storm becomes one incident.
- **Connects to:** AWS, CloudWatch, AWS X-Ray, CloudTrail, Datadog, Prometheus, Elasticsearch, Sentry, Grafana, Axiom, GitHub, Vercel, Trigger.dev, PostHog, PlanetScale, Slack, LangSmith, Logfire and LiteLLM. Kubernetes is available through an outbound connector installed with Helm. Azure, Supabase and Microsoft Teams are coming next.
- **Can change:** fix and revert pull requests, rollbacks through a GitHub Actions workflow your administrator confirms, Kubernetes restarts, scaling and patches, Vercel rollbacks and promotions, staged Trigger.dev replays and PostHog flag rollouts, and PlanetScale deploy requests and backfills. Your team merges and your pipeline deploys.
- **Works with your coding agents:** a read-only MCP server gives coding agents and other MCP clients the full incident context.
- **Access model:** read-only investigation by default. Changes need separate permissions and follow your team's approval policy.
- **In production with:** 7DIGIT, UNICEF and Warestack (deployed via 7DIGIT).
- **Getting started:** [book a demo](https://tryace.dev/book-demo) or [request a quote](https://tryace.dev/pricing). Pilots run on your own incidents with scope and pricing agreed up front.

## A whole team, on the same case

- **Telemetry** follows the failing request and shares the trace that sends the others to the right service.
- **Infrastructure** checks the resources behind the failure and the services that depend on them.
- **Code** tests recent changes against the findings, then prepares the patch and a regression test.
- **Recovery** rechecks the original failure and downstream impact, and reopens the work if recovery fails.

Ace coordinates them on one case, with one evidence trail.

## Know what depends on the failing service

Ace maps the resources and dependencies in your infrastructure. Its agents use that graph to follow a failure across services, even when the alert only names one. See which callers share the failing database, where work is backing up and what a proposed change could affect.

## Review the fix where you ship code

Ace opens a pull request with the patch, the evidence behind it and a test for the failure. Three Ace reviewers check correctness, data safety and operations, and if the pull request fails your checks, Ace makes one follow-up fix. Your engineers review and merge in GitHub.

- **Prevent the next occurrence.** Clearing a queue restores service. A lock timeout, bounded retries and a contention test address the failure that would bring it back.
- **Verify the full recovery.** Ace checks the deployed revision, API latency and downstream backlog. If a symptom remains, the investigation stays open.
- **Supported operational actions.** For example, restoring the last healthy revision of a service, rolling back a Vercel deployment or replaying failed Trigger.dev runs in stages, with preconditions that stop the action if the target has changed. Your permissions and deployment setup determine which actions are available.

## Stop doing the same investigation twice

Ace remembers the cause, the fix and your engineers' feedback, and finds similar incidents across your organization by meaning. Its agents check that history against the current system, reuse what worked and prepare changes that prevent the failure from returning.

## Delegate more as Ace earns it

Give Ace a defined part of the operational work. Start with investigations, then authorize specific actions once you have reviewed the results. Your team sets the scope, limits and approval rules.

| Step                       | Boundary           |
| -------------------------- | ------------------ |
| Investigate                | Read-only access   |
| Prepare a change           | Review required    |
| Execute an approved action | Within your policy |
| Verify and remember        | Evidence retained  |

## Your tools, one investigation

Ace reads from your cloud, observability, delivery and code tools, then posts updates and approval requests in the incident's Slack thread, where each agent appears as its own teammate. See [integrations](https://tryace.dev/integrations).

## Start with the incidents your team knows

Test Ace against real incident work. Agree on the systems it can access, the cases it should handle and the engineer time you want to save. Scope and pricing are agreed before you start. See [how pricing works](https://tryace.dev/pricing).

---

The incident shown on the website (orders stalled after a schema change) is an illustrative example, not a customer outcome.