Inspiration

Engineering teams often manage incidents through scattered Slack threads, GitHub commits, deployment logs, and tribal knowledge. During an outage, responders lose valuable time asking the same questions. What changed? Who owns the service? Has this happened before? What should happen next?

I built OpsPilot to turn Slack into an intelligent incident response workspace. Instead of forcing engineers to switch between multiple tools, OpsPilot brings investigation, repository intelligence, coordination, and follow up directly into the conversations where teams already work.

What it does

OpsPilot is a Slack native AI incident commander and repository intelligence agent.

Teams can install OpsPilot into their Slack workspace, connect a GitHub repository, and interact with it through slash commands or natural language mentions.

OpsPilot can investigate incidents from commands such as /opspilot investigate checkout API is failing, analyze recent GitHub commits and changed files, correlate code changes with deployment signals and incident history, estimate severity, identify likely root causes, and recommend next actions.

It can also explain its reasoning through conversational follow up questions, create dedicated incident channels, generate timelines, status updates, postmortems, runbooks, test plans, and release notes, and audit connected repositories for risky changes, configuration concerns, migration impact, and release readiness.

The main product experience lives inside Slack. The web application handles onboarding, integrations, project setup, documentation, and command discovery.

How I built it

I built OpsPilot with Next.js, TypeScript, Tailwind CSS, Slack APIs, GitHub APIs, OpenAI, PostgreSQL, Neon, and Vercel.

The Slack integration includes signed slash command endpoints, Slack Events API support for @OpsPilot mentions, interactive Block Kit buttons, Slack OAuth for multi workspace installation, workspace specific bot token resolution, and thread aware conversational responses.

The agent uses a modular tool architecture. An evidence aggregator runs independent tools for Slack context, GitHub changes, deployments, service ownership, and historical incidents. These results are converted into structured evidence before being passed to the reasoning layer.

OpenAI structured outputs can generate incident reports from the available evidence. To keep the application reliable, every AI workflow includes deterministic fallback behavior, and external integrations can fail safely without breaking the Slack experience.

I also added per workspace GitHub OAuth so teams can connect and select their own repositories. Repository audits inspect recent commits, changed file metadata, sensitive paths, migrations, authentication changes, configuration files, and other operational risk signals.

Persistent incident memory and installation data are stored in Neon PostgreSQL through a lightweight database layer. The application is deployed on Vercel, with serverless API routes handling Slack events, OAuth callbacks, repository access, project configuration, and incident storage.

Challenges I ran into

One of the first challenges was realizing that the website was not the main product. OpsPilot needed to feel native to Slack rather than like a web application with a chatbot attached. I redesigned the product around slash commands, mentions, threads, and interactive Slack workflows.

Slack response timing also required careful architecture. Commands and event requests had to be acknowledged immediately while longer investigations continued asynchronously.

Permissions and workspace behavior created several practical issues. The bot initially failed to post final results because it had not been invited to the channel. Interactive buttons were also routed to the wrong endpoint until the interactivity configuration was corrected.

Multi workspace SaaS support was another major challenge. A single environment level Slack token or GitHub repository was not enough. I added Slack OAuth, GitHub OAuth, installation persistence, workspace specific token lookup, and project configuration so each team could connect its own environment.

I also had to prevent real GitHub data from being combined with unrelated deterministic incident assumptions. This led me to separate incident investigation from repository audit workflows and create distinct context aware agents for each.

Finally, serverless persistence required moving from process memory to PostgreSQL so conversations and incident context could survive deployments and work across multiple Vercel instances.

Accomplishments that I am proud of

I am proud that OpsPilot evolved from a single slash command prototype into a working multi workspace SaaS application.

The complete flow now works from end to end. A user can install OpsPilot from the website, connect a Slack workspace through OAuth, connect a GitHub repository, configure project context, investigate incidents, audit repositories, ask follow up questions, create incident channels, generate postmortems, and preserve context across deployments.

I am also proud of the system's reliability. External services, AI responses, database operations, and repository access all have safe fallback behavior. The agent remains usable even when one source is missing or unavailable.

What I learned

I learned that building an agent is less about placing an LLM behind a chat box and more about designing trustworthy workflows around tools, context, permissions, and structured actions.

I gained a much deeper understanding of Slack OAuth, the Events API, slash commands, interactivity, Block Kit, request signing, GitHub OAuth, multi tenant token management, structured AI outputs, deterministic fallback design, thread aware memory, PostgreSQL persistence in serverless environments, and SaaS onboarding.

I also learned the importance of clearly communicating limitations. OpsPilot distinguishes between metadata based repository analysis and full runtime verification, and it reminds users that AI recommendations should be reviewed before operational changes are made.

What's next for OpsPilot

The next step is expanding OpsPilot from repository and incident intelligence into a broader engineering operations platform.

Future improvements include production Slack Real Time Search, deployment integrations with Vercel, Render, GitHub Actions, and other providers, pull request and CI analysis, automatic service discovery for monorepos, repository wide code indexing, semantic search, runbook integrations, observability integrations, encrypted token management, incident analytics, role based access controls, and Slack Marketplace publication.

My long term vision is for OpsPilot to become an AI engineering teammate that understands a team's codebase, systems, incidents, and operational history, then helps engineers act on that knowledge without leaving Slack.

Built With

Share this project:

Updates