AutoOps

Cited operational context for faster, safer on-call triage.

Comment

Inspiration

AutoOps was inspired by a very real on-call problem: during incidents, the information needed to triage safely is rarely in one place. A PagerDuty alert may point to one runbook, but the latest operational context might be in a Jira ticket, a Slack thread, a GitLab page, or a Google Doc. Even when the right runbook exists, engineers still need to check whether it is stale, whether there was planned maintenance, whether previous incidents followed a different workflow, and who owns the affected service.

That search can take 15-30 minutes, which is painful when an alert escalation window may only be 30 minutes. AutoOps was built to compress that search into a single cited, timeline-aware response.

What It Does

AutoOps is a safety-first SRE knowledge hub for on-call engineers.

It ingests local mock operational knowledge from Confluence-style runbooks, GitLab docs, Google Docs-style SOPs, Jira tickets, PagerDuty alerts, and Slack-style discussions. When queried, it returns:

  • A direct answer
  • Source-supported remediation steps
  • Citations for every source used
  • Source type, title, path, version, and update timestamp
  • Timeline and freshness notes
  • Contradiction flags when sources disagree
  • Missing-context gaps
  • Confidence level
  • Safety warnings before remediation is trusted

The current prototype runs fully locally with mock data and sanitized connector fixtures. It does not require real company data or live third-party accounts.

How I Built It

AutoOps was built with Python, FastAPI, SQLite, SQLite FTS5, and Docker. The system has three main interfaces:

  1. A CLI for ingestion, querying, fixture sync, refresh workflows, and demos.
  2. A FastAPI API for local service access.
  3. A browser demo for judges and users to try the core workflow.

The ingestion pipeline normalizes mock source documents into a SQLite knowledge store. Each document is split into searchable chunks and indexed with SQLite FTS5. Query responses are assembled from retrieved sources, then enriched with remediation extraction, timeline notes, contradiction detection, confidence scoring, and safety warnings.

For Phase 2, I added fixture-backed connectors for Confluence, GitLab, and Jira. These simulate connector behavior without calling live APIs. The refresh workflow supports manual and cron-compatible scheduled refreshes, records sync metadata, and stores raw source payload metadata in hash-only mode by default.

Safety was built into the prototype from the start. AutoOps blocks secrets, customer/external email addresses, private-key-like content, bearer tokens, and sensitive-looking payloads before they reach the knowledge store.

How Codex And GPT-5.6 Helped

Codex with GPT-5.6 was used as the main development partner throughout the project. It helped turn the original SRE workflow pain point into a phased SDLC plan, choose a no-cost local prototype stack, design the SQLite schema and source metadata model, and implement the CLI, API, ingestion pipeline, query engine, browser demo, refresh workflow, Docker packaging, and fixture connectors.

Codex also helped generate realistic mock data and edge cases, including stale runbooks, contradiction scenarios, non-PagerDuty Jira tickets, planned maintenance, production changes, access requests, and Slack-style discussion summaries.

A major benefit was using Codex to keep the project disciplined: each phase had gates, tests, review points, and explicit approval before moving into higher-risk functionality. That helped keep the current submission focused on the trusted knowledge layer before attempting automation.

Challenges

One challenge was balancing usefulness with safety. The system should suggest remediation steps, but it should not pretend those suggestions are guaranteed correct. To handle this, AutoOps always cites sources and includes an explicit warning that remediation may be incomplete or incorrect.

Another challenge was modeling real-world operational knowledge without using real company data. I solved this with mock source files and sanitized API-style connector fixtures that represent the types of edge cases SREs actually encounter.

A third challenge was handling contradictions. In real operations, older runbooks, Slack messages, and incident notes can disagree. AutoOps does not automatically decide which source is correct. Instead, it flags contradictions and shows timeline context so the on-call engineer can review the evidence.

What I Learned

I learned that an agentic operations system is only as trustworthy as its knowledge layer. Before automating ticket triage or alert response, the system needs strong foundations: source citations, timeline awareness, safety filtering, version tracking, contradiction detection, and clear confidence signals.

I also learned that mock data can be extremely powerful when it is designed around realistic operational edge cases. It made the prototype safe to build and easy for judges to run, while still demonstrating the product direction clearly.

What's Next

The next phase is event-triggered retrieval: when a Jira ticket or PagerDuty alert arrives, AutoOps should automatically gather the relevant runbooks, prior tickets, alert history, Slack discussions, planned maintenance context, and ownership details.

Later phases can assist with triage automation, such as adding labels and components to Jira tickets, acknowledging tickets, posting PagerDuty alerts to Slack, creating linked Jira tickets, and notifying on-call engineers.

I also created a future-scope branch for hybrid search that explores combining SQLite FTS, local embeddings, and structured metadata filters. The stable submission keeps that separate so judges can test a reliable baseline while still seeing the future direction.

Built With

Share this project:

Updates

Submission history