Operate is a self-hosted AI SRE: an AI agent platform that detects, investigates, and resolves production issues. It runs a four-agent pipeline (Context, Root Cause, Verification, and Resolution) that connects to your logs, database, and codebase, then produces an evidence-backed root cause and a draft pull request for human review.

An AI SRE is an AI system that does the work of a site reliability engineer: watching production for errors and regressions, investigating alerts, finding root causes, and proposing fixes. Operate is a self-hosted AI SRE, so it runs inside your own infrastructure with read-only access and a mandatory human approval gate.

How does Operate find the root cause of a production issue?

When triggered from chat (Slack, MS Teams, and other tools) or by an automated alert, Operate pulls traces from log providers like Datadog, CloudWatch, GCP Cloud Logging, and SolarWinds, queries your MongoDB, PostgreSQL, or MySQL database in read-only mode, and reads your codebase via git including blame and diff. A Context Agent gathers signals, a Root Cause Agent proposes a cause with a confidence score, a Verification Agent independently checks the reasoning with a different model, and a Resolution Agent drafts a fix as a pull request.

Does Operate ship code automatically without a human?

No. Operate stops at a draft pull request. A human engineer must review and merge; nothing ships without approval. Every agent step is auditable so reviewers can see the evidence and reasoning behind each finding.

How is Operate deployed?

Operate is deployed as a Docker image into your existing infrastructure with no new cloud accounts. It runs on port 8080 under the /operate path, requires MongoDB and Redis, and uses an App ID from operate.bettrsw.com. It connects via read-only adapters to logs, databases, and observability stacks, and clones your repo at startup via an init container so agents have full git history.

Which integrations does Operate support?

Operate's context layer spans 60+ integrations across 14 categories: source control (GitHub, GitLab), logs (Datadog, CloudWatch, GCP Cloud Logging, SolarWinds), databases (MongoDB, PostgreSQL, MySQL, read-only), error tracking (Sentry, Rollbar), APM (New Relic, Grafana, OpenTelemetry), CI/CD (GitHub Actions, Jenkins, Vercel), feature flags (LaunchDarkly, Statsig), cloud infrastructure (AWS, GCP, Azure, Kubernetes), queues (Kafka, SQS, RabbitMQ), incident management (PagerDuty, incident.io), issue tracking (Jira, Linear, Asana), support (Zendesk, Intercom), status pages, and docs (Confluence, Notion). Triggers: Slack, MS Teams, and other chat tools for on-demand RCA, plus the observability stack for proactive monitoring. AI providers: Anthropic Claude, OpenAI/Azure Codex, enterprise models, or self-hosted open-source LLMs.

How does Operate avoid hallucinated root causes?

Operate uses a two-model verification step. The Root Cause Agent proposes a cause with specific evidence; the Verification Agent, running on a different model to avoid correlated errors, independently evaluates the reasoning. Speculative or unsupported conclusions are rejected before reaching the team.

Why not just point an LLM at our logs ourselves?

An LLM has no inherent knowledge of your logs, schemas, services, or known-bad patterns. Operate provides the connectors, permissions, query layer, repo context, multi-agent verification, and operational runtime that turn a generic model into a reliable production-investigation system.

Engineering teams that lose 30–40% of capacity to unplanned investigation: support escalations, error alerts, performance regressions. With Operate, support and product teams can trigger an RCA from Slack, MS Teams, or whatever chat tool they use, and only loop in engineers when a decision needs to be made.

← All repos

github

etcd-io/etcd

Pick an open issue and Operate will investigate its root cause.

113 open issues

#22123 concurrency: Election.Resign forgets leadership after a failed request
#22094 client/v3: closeRequireLeader leaves an orphaned keepAlives entry that keeps sending keepalive requests forever
type/bug
#22090 `etcdutl init`: initialize a member's data directory offline, without a snapshot file or a running server
#22086 ordering: Txn.Commit reissues a mutable transaction after a revision violation
#22085 naming/endpoints: DeleteEndpoint can delete multiple endpoints through range options
#22084 leasing: LockWriteOps range branch races with lease-cache mutation
#22083 leasing: Delete with WithFromKey removes leasing protocol keys
#22082 concurrency: stale Mutex.Unlock retry can delete a newer same-session lock
#22081 client/v3: KeepAlive subscriber may get the wrong channel closed after leader loss
type/bug
#22079 Add a metric for the size of current live KV data
type/feature
#22065 gRPC proxy serializable Range cache can leak protected KV data across auth contexts
type/bug
#22028 Verification failed in Antithesis: backend.ConsistentIndex (1049) must be <= WAL.HardState.commit (1047)
area/robustness-testing
#22027 [Antitheis] Panic in finally
area/robustness-testing
#22026 Feature request: support live DNS/source-IP verification for peer hostnames as an alternative to SAN-only allowlisting
type/feature
#22013 Etcd server apply request took too long
type/bug
#21986 backend: stale single-key read after intra-batch overwrite (merge no-overlap fast-path skips dedupe)
#21980 Flaky `TestCompactionHash`
area/testing
type/flake
#21969 client/v3: panic: send on closed channel in watchGRPCStream.broadcastResponse
#21966 Panic in `IsLocalMemberLearner` when `Maintenance/Status` is called concurrently with member removal
type/bug
#21961 Code Health Audit — 3,078 findings (1,154 http URLs, 182 long funcs, 142 TODOs)
#21928 Robustness test linearization OOM
type/bug
#21912 CI: Measure TestGrid Flakiness workflow fails due to DNS resolution error for testgrid-data.k8s.io
#21908 Mixed-version robustness test failing
#21864 Performance investigation for robustness test
area/testing
type/flake
#21852 Deflake TestEtcdHealthyWithTinySnapshotCatchupEntries
area/testing
type/flake
#21828 Continuous reporting and graceful termination in benchmark tool
type/feature
#21813 grpcproxy: new watchers may be added to a disconnected watchBroadcast and miss all subsequent events
type/bug
gRPC-proxy
#21767 [Bug] v3.7.0-beta.0: Control-Plane Deadlock and Cluster Consensus Availability Loss During Single-Node Downgrade
type/question
#21740 ETCD learner members cannot be defragmented, causing persistent storage bloat.
type/bug
#21724 feature(etcdctl): support customized configuration for `check perf` command
type/feature