-
-
One-click recovery runbook runs each step and reports results inside the thread, with root cause and impact.
-
opened the incident itself, before anyone asked, with severity, diagnosis, and a fix recalled from memory of 3 past incidents.
-
new Slack agent_view experience, combining live AWS logs, Slack Real-Time Search history, and Amazon Bedrock reasoning.
-
Acknowledge and Escalate actions assign ownership and page on-call, keeping the whole incident lifecycle inside Slack.
-
One-click branded incident report with the live CloudWatch log table and clickable related Slack history.
The problem
It is 2 AM and something is on fire. Payments are failing, Slack is lighting up, and the on call engineer is now juggling five tabs. CloudWatch in one, a runbook in another, and a frantic scroll through three months of Slack history trying to remember how someone fixed this exact thing last time.
Here is the painful part. The answer almost always already exists. Someone has seen a version of this before. The logs already say what is wrong. But that knowledge is scattered across tools and buried in people's heads, and under pressure nobody can find it fast enough. Every minute lost is a customer lost.
We built ContextOps to close the gap between the alert and the answer.
What it does
ContextOps is an incident response agent that lives inside Slack. You talk to it like a teammate, in a channel or a direct message, and it goes to work immediately.
It pulls your live AWS CloudWatch logs, searches your Slack history for similar past incidents, and reasons over both to give you a clear diagnosis, the likely root cause, the real world impact, and a recommended next step. All in seconds, right where the panic is happening.
Three things make it feel less like a search box and more like a real engineer:
It acts before you do. When a monitoring alarm fires, ContextOps opens the incident itself and posts it, before anyone asks.
It remembers. Every incident and its resolution is saved. When a similar failure happens again, ContextOps recalls the fix that a human already verified and says so, with high confidence, instead of guessing. It genuinely gets better every time it is used.
It does the paperwork. One click writes a full incident report on a clean branded page and a native Slack Canvas postmortem, so documentation stops being the job everyone avoids.
You can also run recovery runbooks straight from the message, acknowledge or escalate with a button, and watch everything roll up into a Home tab dashboard with mean time to resolve trending down as the agent learns.
How we built it
ContextOps is a Python and FastAPI service running on AWS EC2. Slack events flow in through Slack Bolt, and the agent uses the newly released agent_view experience, so conversations look and feel like a normal direct message and the agent behaves as a persistent, conversational engineering teammate right inside the thread.
For reasoning it calls Amazon Bedrock with Amazon Nova, turning raw logs and past incidents into a structured diagnosis. AWS CloudWatch Logs provides the live telemetry through a custom Model Context Protocol (MCP) server integration, and the Slack Real-Time Search API surfaces relevant history from past conversations. A database holds the growing memory of resolved incidents that powers the learning loop. Reports render as styled HTML, get stored in Amazon S3, and are served back through short human friendly links, with a Slack Canvas generated alongside them.
We cared a lot about the small things that make an agent trustworthy. It filters out its own messages so it never cites itself. It degrades gracefully when a model or API is unavailable instead of crashing. And every reply is structured, so the output is always clean rather than a wall of raw model text.
Challenges we faced
The hardest parts were the quiet ones. The Slack Real-Time Search API needs a user token, not a bot token, and finding that distinction cost real time. Getting Amazon Bedrock model access on a fresh account meant working through a billing and subscription maze. And teaching the agent to stop treating your own question as a past incident took several rounds of filtering. Each fix made the product noticeably calmer and more reliable.
What we learned
The value of an incident agent is not fancy AI. It is removing friction at the exact moment a human is stressed. Every decision came back to one question. Does this save the on call engineer a step. That focus shaped everything, from the short report links to the learning loop to the graceful fallbacks.
What is next
Live metrics and alarms alongside logs, deeper one click remediation against real control planes, and a shared memory that turns every team's outages into institutional knowledge that never walks out the door.
Built With
- amazon-bedrock
- amazon-ec2
- amazon-nova
- amazon-web-services
- aws-cloudwatch-logs
- aws-iam
- boto3
- fastapi
- model-context-protocol-(mcp)
- nginx
- python
- slack-agent-view
- slack-block-kit
- slack-bolt
- slack-canvas
- slack-real-time-search-api
- sqlite
- systemd
Log in or sign up for Devpost to join the conversation.