Introducing Aurora Actions: background agents that run your SRE workflows

Key Takeaways

• Aurora Actions are background agent tasks that follow your instructions: you write what you want done in plain English and Aurora runs it as a background agent using your connected tools.
• You control three things per Action: when it runs (manually, on an incident, or on a schedule), what it can do (read-only or read-write), and the task itself, written as natural-language instructions.
• Read-write Actions can run commands, modify infrastructure through Terraform, and open pull requests, and they are instructed to propose changes as a PR rather than applying them directly so a human stays in the loop.
• One Action ships built-in: Generate Postmortem, which writes a structured postmortem when an incident resolves. Use cases like muting noisy Datadog alerts via Terraform, scanning a repo for security issues, and reviewing PRs for risk are ones you build yourself.
• Aurora is open source (Apache 2.0) and self-hosted, and Actions is available now.

Today we're introducing Aurora Actions: background agent tasks that follow your instructions. Write what you want done in plain English, choose how and when it should run, and Aurora carries it out as a background agent using the tools you have already connected.

Actions are deliberately open-ended. The same primitive that mutes a noisy alert can review a pull request, scan a repository for security issues, or write a postmortem. You describe the outcome, and the agent works out the steps.

Three choices, then it runs

Every Action comes down to three decisions:

• What it does. You write natural-language instructions. Aurora receives them along with context about whatever triggered the run, like the incident details or alert data, and executes them with your connected tools.
• When it runs. A trigger: manually, on an incident, or on a schedule.
• What it is allowed to do. An execution mode: read-only or read-write.

Pick how it triggers

• Manual only. Runs when you trigger it from the Actions page or an incident.
• On incident. Fires automatically when an incident comes in. You choose the moment: the instant it is created, after root-cause analysis completes, or once it is resolved.
• On schedule. Runs on a recurring interval, down to every five minutes.

Pick what it can touch

• Ask (read-only). Aurora can investigate, query your tools, and read code, but it cannot change anything. Write access is filtered out.
• Agent (read-write). Aurora can run commands, modify infrastructure through Terraform, and open pull requests. By default it is instructed to propose changes as a PR rather than applying them directly, so a person stays in the loop on anything that touches production.

What you can build

A few of the things an Action can do:

• Mute noisy Datadog alerts via Terraform. Tell Aurora to find the Terraform config that defines a monitor in your repo, add a mute or downtime rule, and open a PR that explains why the alert was noisy. Aurora reads the alert, finds the config, makes the change, and opens the PR.
• Scan a repository for security issues. Put it on a schedule in read-only mode and let it sweep your code on its own cadence.
• Review pull requests for risk before they merge.

The last two are not pre-built. You create them as Actions yourself, using Aurora's read-only access to your code and pull requests. One Action does ship built-in:

• Generate a postmortem automatically. When an incident resolves, Aurora pulls the root-cause analysis and the relevant Slack context and writes a structured postmortem, with sections for timeline, root cause, impact, action items, and lessons learned.

Results do not start from scratch each run. Every Action keeps a living document that it reads and updates on each pass, reconciling new findings against what is already resolved and anything you have marked as a false positive, so results build up over time instead of resetting.

Built to act on production safely

Handing an agent write access to infrastructure is not something to do casually, so the guardrails are part of the design:

• Read-only is a first-class mode. If an Action only needs to look, it cannot touch anything.
• Read-write Actions are instructed to open pull requests instead of applying changes directly, keeping a human review step on real changes.
• Every run is logged and linked to a full session you can open and inspect.
• Instructions pass through input safety checks before anything executes.
• Access is scoped per organization with role-based permissions.

Available now

Aurora is open source and self-hosted, and Actions is available today in the Actions tab. Connect your tools, write your first instruction, and let it run.

For a deeper look at how Actions work under the hood, including trigger internals, RBAC, and the safety practices we use ourselves, read our Aurora Actions deep dive.