Incident → PR: with enterprise guardrails
When a bad deployment spikes the error rate and breaches an SLO, Randoli's SRE Agent (Raiya) takes over. It runs a root cause analysis, then follows a runbook your team pre-approved: investigating logs and traces, analyzing the code, and opening a pull request.
- Your engineers review the evidence and decide what ships.
- Raiya runs in your own environment, with the permissions and tools you define.
- It only executes runbooks written by your team.
- Your telemetry stays where it lives, so AI-assisted incident response doesn't mean giving up data sovereignty.
What you'll see in the demo
- The incident: a deployment introduces a bug, the error rate spikes, the SLO is breached, and a monitor triggers an incident.
- The evidence: the monitor's threshold and incident criteria, and a pre-selected runbook that has the agent investigate logs and traces.
- The root cause: the incident view shows the root cause analysis and each runbook step as it executed.
- The code analysis: the agent looks at the code and works out what went wrong.
- The PR for review: the agent creates a pull request for your team to review, plus a Jira ticket with the PR details and a link.
Related
- AI-Driven Incident Response: How Raiya takes an incident from alert to root cause under guardrails your team defines.
- Data Sovereignty in the Age of Autonomous Observability: Why we move the agent's reasoning to where the data lives, and send only findings and evidence to the control plane.
Transcript
Hi, I'm Rajith from Randoli. I'm going to do a quick demo to show you how an autonomous SRE agent can take you from incident detected to pull request without any human involvement, while adhering to enterprise guardrails. Let me walk you through the scenario. Assume you're doing a deployment and it introduces a bug. Your error rate spikes and your SLO is breached. Now that triggers an incident. The SRE agent will take over from here. It'll run a root cause analysis, and then the agent will execute a pre-approved runbook provided by your team. The runbook has the following steps. It investigates the logs and traces. It looks at the code, detects the issue, and creates a PR for your team to review. Then it creates a Jira ticket and adds the details, as well as a link to the PR. Let's see how that works in practice. Over here, you can see that during this time the deployment was made, which introduced the error that caused the error rate to spike. And that resulted in a monitor being triggered. Here's how the monitor looks, where you can see a threshold being configured. It gets exceeded, and the incident criteria is defined. And what's important here is that you pre-select the runbooks that you want to run, bringing in those enterprise guardrails, where approved and vetted actions get executed for a given incident. Next up, let's look at the incident that got created. So you can see over here the root cause analysis. And over here, you can see the runbook has executed with the following steps, where it looked at the code and figured out the issue, created the PR, created a ticket, and updated the link. This is what the PR looks like. It looked at the data and created a pull request. And over here is where the SRE agent ended up creating the Jira ticket and added the pull request details. This is just one workflow that you could build with the autonomous SRE agent. Think of it as a framework. You can build many more workflows like this in response to incidents, as well as other triggers that you get through our observability platform, by connecting your tools like Slack, Jira, ServiceNow, GitHub, etc., to build workflows to help and augment your human SRE team.