The open-source AI SRE that finds the root cause in minutes.

Free to start, fully hosted. No setup required. Prefer to keep data in-house? Self-host or run it in your own VPC.

Get started freeBook a demo
app.aurora-ai.net/incidents

Incidents

✓ Analyzed

Trusted by teams that keep uptime in check

Google
McGill University
Verizon
Harbor Fab
Guzzo Nano Research
Canoe Interpretation
Google
McGill University
Verizon
Harbor Fab
Guzzo Nano Research
Canoe Interpretation
Explore Features Below

Aurora sits between your alerts and the answer

Your tools tell you something broke. Aurora tells you why.

aurora setup
AuroraAurora

Root cause found
in minutes.

Alert fires, Aurora investigates every signal across your stack, and delivers the exact root cause, with evidence.

Explore the features

Fully autonomous actions

Autonomous agent sessions

Plain-language instructions, a trigger, and Aurora runs a full investigation with your tools. No human in the loop unless you want one.

app.aurora-ai.net/actions

Actions

Background agent tasks that follow your instructions

Total Actions

2

Active

2

Enabled and triggering

Total Runs

29

Self-updating artifacts

Living documents that stay current

Every action produces a versioned artifact. The agent reconciles changes, drops resolved findings, preserves your edits. Every version is restorable.

app.aurora-ai.net/monitor

monitoring-coverage · payments-svc

Version 4

Monitoring Coverage, payments-svc

Reconciled against v3 on the latest Alert Gap Audit run.

•Added, latency SLO alert (p99 > 400ms, 5m)

•Added, saturation alert on the Redis connection pool

•Removed, error-rate alert (now shipping in PR #388)

•Kept, your 3 manual annotations on the deploy webhook

Coverage now: 4 / 4 Golden Signals.

Industry-leading guardrails

Four layers before any command runs

Injection rail, signature matcher, org policy, LLM judge. Foreground chats prompt for approval. Background runs fail closed.

app.aurora-ai.net/chat
Policy Templates
Observability Only
24 allow15 deny
Apply
Standard Operations
24 allow14 deny
Apply
Full Cloud Access
18 allow13 deny
Active
Denylist
\brm\s+--?rf\s+/Recursive root deletion
\b(gcc|g\+\+|cc|make|as|ld)\bNative code compilation
(?<!\bkubectl\s)(?<!\boc\s)(?<…Dynamic code evaluation
\bLD_PRELOAD\bShared library injection
\bbase64\b.*\|\s*(sh|bash|pyth…Encoded payload execution
Test Command
Enter a command to test...
Test
Compounding knowledge base

Every incident makes the next one faster

Org memory follows every investigation. Runbooks are searchable mid-incident. Good RCAs become paths the next incident inherits automatically.

app.aurora-ai.net/knowledge-base
Memory

Context Aurora always remembers, injected into every conversation.

## Service Map
- prod-api: main gateway · prod-db: Cloud Spanner
## Escalation
- Spanner issues: @db-oncall
312 / 5000 charactersSave
Documents

Runbooks and docs Aurora searches mid-investigation, hybrid keyword + semantic retrieval.

runbook-payments.md

84.2 KB · 37 chunks

Ready

architecture-overview.pdf

2.1 MB · 112 chunks

Ready

oncall-escalation.txt

11.4 KB

Processing

See Aurora Investigate

A P1 checkout outage the Payments team blamed on a slow database. Across PagerDuty, Datadog, AWS, Kubernetes, and GitHub, Aurora traces it to a one-line migration bug, in six minutes.

Aurora Chat
PagerDuty P1: checkout p99 latency > 8s, error rate climbing. Payments team says "database is slow." Can you find the real root cause?

On it. "Database is slow" is a symptom, not a cause. Let me start from the alert itself and the blast radius, then work backward through the telemetry. First, the PagerDuty incident and the current service health.

PagerDutypagerduty.get_incident(id="PXY8K2")
Datadogdatadog.query("avg:trace.http.request.duration{service:checkout-api} by {resource}", from="-2h")

Key signal: it's a step change at 02:41 UTC on a single endpoint, /checkout/submit. Step changes almost always mean a deploy or a config change, not organic load. Let me pull the flamegraph for that endpoint to see where the time is actually spent.

Datadogdatadog.get_trace_analytics(service="checkout-api", resource="POST /checkout/submit", percentile=99)
AWSaws rds describe-db-instances --db-instance-identifier orders-db-primary --query 'DBInstances[0].{Class:DBInstanceClass,CPU:...,Status:DBInstanceStatus}'
AWSaws rds download-db-log-file-portion --db-instance-identifier orders-db-primary --log-file-name error/postgresql.log --starting-token 02:40

Now we're at the mechanism: 60+ INSERTs are serialized behind one long-held transaction (PID 4402) holding a ShareLock. The hardware is fine, this is pure lock contention. I need to know what PID 4402 is doing and what changed at 02:41. Let me inspect the blocking query and correlate with recent deploys.

Datadogdatadog.query("postgres.pg_stat_activity{db:orders,pid:4402}", detail=true)
github.list_deployments(repo="beng360/orders-service", environment="production", since="2026-07-02T02:00Z")
github.get_file(repo="beng360/orders-service", path="migrations/0042_add_status_index.sql", ref="d9f4a12")

That's the root cause. Let me confirm the failure mode is real by checking the migration runner's logs and the downstream blast radius before I write it up.

Kuberneteskubectl logs job/orders-migrate-d9f4a12 -n orders --since=10m
Datadogdatadog.query("sum:trace.errors{service:payments-worker,error.type:timeout}", from="-1h")
Jirajira.create_issue(project="REL", type="Incident", link_pr=true)

Root Cause: Silently Downgraded Concurrent Index Build


The checkout outage is not a database performance or capacity problem. The RDS instance is healthy (14% CPU). It is a write-blocking lock introduced by migration 0042.


The mechanism, end to end:


1. Migration 0042 deployed at 02:40:33 UTC. It runs CREATE INDEX CONCURRENTLY, but wraps it in a BEGIN/COMMIT block.


2. Postgres does not allow CONCURRENTLY inside a transaction, so it silently ran a standard CREATE INDEX, which takes a lock that blocks all writes to the orders table.


3. Every INSERT from payments-worker queued behind the index build (61+ deep). p99 on /checkout/submit jumped from 440ms to 8.3s at 02:41.


4. Blocked writes saturated the connection pool (198/200), which is what the Payments team saw as "database is slow." That was a downstream symptom, two hops from the cause.


Impact: ~$47K in abandoned checkouts over 7 minutes, 2,140 gateway timeouts, an SQS retry storm on payments-worker.


Immediate mitigation: Terminate PID 4402 (SELECT pg_terminate_backend(4402)) to release the lock, writes drain instantly. Re-run 0042 outside a transaction block.


Prevention: Migration runner must not wrap files containing CONCURRENTLY in BEGIN/COMMIT. Add a CI lint rule to reject that combination.

slack.post_message(channel="#incident-checkout", blocks=rca_summary)

Your agents' source of infrastructure truth

Aurora exposes your full operational context over MCP, incidents, topology, runbooks, blast radius, RCA findings. Any agent that speaks the protocol gets live access. Zero integration work.

Open source. Self-hosted. Your data never leaves your network and is never used for model training.

Claude CodeCursorOpenClaw+ any MCP client
claude, ~/orders-api
>Claude CodeClaude Code→aurora mcp connected✓
PagerDuty just fired for order-processor-prod. Let me pull context from Aurora.
▸aurora.get_incident("INC-4821")
severity: critical | triggered: 2m ago alert: "DB connection pool exhaustion" service: order-processor | region: us-east-1
Connection pool exhaustion. Let me check the infrastructure topology.
▸aurora.get_infrastructure_context("order-processor-prod")
Lambda (python3.11, 256MB) trigger: SQS order-processing-prod DB_HOST: orders-db.cluster-abc123.rds.amazonaws.com
Let me check if there are known issues with this service.
▸aurora.search_knowledge_base("order-processor connection pool")
1 match: RCA-45 (resolved 2026-05-20) client.release() missing, fixed in v2.4.1
Already fixed. Let me look at the actual logs.
▸aurora.get_service_logs("order-processor-prod", { limit: 30 })
6 invocations, 6 errors (100% failure rate) ImportModuleError: No module 'psycopg2._psycopg' socket.gaierror: Name or service not known
DB_HOST doesn't resolve. Let me verify the RDS state.
▸aurora.query_cloud("aws rds describe-db-instances")
No PostgreSQL RDS instance exists. "orders-db.cluster-abc123", placeholder, never provisioned.
The endpoint is fake. Let me check how this was deployed.
▸aurora.get_source_file("beng360/order-processor", "deploy.sh")
DB_HOST=orders-db.cluster-abc123... # ^^^ HARDCODED PLACEHOLDER, never replaced
▸aurora.get_blast_radius("order-processor-prod")
order-processor: 100% failure (12 days) SQS DLQ: 72 msgs near retention limit billing-service: degraded
▸aurora.submit_rca("INC-4821", { root_cause: "deploy.sh bypasses SAM" })
RCA submitted → #incident-order-processor Fix: run sam deploy, disable SQS trigger, remove deploy.sh
▸

Open source you don't have to operate

Self-host it free, or let us run it, with your data staying in your own cloud. The paid tiers are about operating Aurora at scale, never about unlocking it.

Aurora Open Source

Self-hosted, Apache 2.0

Free forever

  • Full root-cause analysis, no feature gates
  • Runs entirely in your infrastructure
  • Apache 2.0, audit every line
  • Multi-cloud + 22 integrations
Get started on GitHub
Flagship

Aurora Managed

We operate it, as SaaS, or inside your own cloud.

Talk to us

  • Run it as SaaS, or in your own VPC, your call
  • Deploy in your cloud and telemetry never leaves it
  • SSO/SAML, RBAC, audit logs, SLAs
  • Managed upgrades, model gateway & support
  • Fleet management across teams & regions
Book a demo

Our commitment: Aurora's core stays open source under an OSI-approved license, and self-hosted Aurora does real root-cause analysis for free, forever. We monetize operating it at scale, never by holding your data hostage.

Backed by

Panache VenturesFront Row Ventures

Frequently Asked Questions