The SRE Agent is now generally available in Dynatrace.
When Dynatrace opens a problem, the SRE Agent takes it from there, analyzing the incident in minutes, not hours: it autonomously performs deep investigation on a determined root cause, triages the incident based on severity assessment, impacted users and entities, and blast radius, and routes to the responsible team the moment the alert fires.
By the time the user opens the problem, they get the incident summary and remediation proposal, right where they already work, with all the context needed: in Slack, Microsoft Teams, via email, JIRA, ServiceNow, or their ticket system. That’s operations moving from reactive to autonomous: Autonomous when you want it, with the agent owning the investigation; and human-approved when it matters, with the user owning the decision.
The first hour after a problem occurs
It’s 2:13 at night when the alert goes off: checkout is failing, and you know it’s critical. The engineer on call wakes up, opens five tabs, and tries to answer one question: Can this wait until morning, or do I need to wake up the team that owns checkout, the database team, or the person who runs major incidents?
It’s 2:13 at night when the alert goes off: checkout is failing, and you know it’s critical. The engineer on call wakes up, opens five tabs, and tries to answer one question: Can this wait until morning, or do I need to wake up the team that owns checkout, the database team, or the person who runs major incidents?
If the engineer determines that it can’t wait, more people get pulled in, and the first hour goes into figuring out what broke, who’s affected, and whose job it is to fix it. Nobody has started fixing anything yet.
How does the SRE Agent investigate and triage problems?
The moment Dynatrace opens a problem, the SRE Agent starts investigating. Within minutes, its findings are ready:
- The cause, contextualized: What Dynatrace found, explained in plain words.
- The SRE Agent’s findings: the evidence behind it, such as errors in the logs, unusual numbers, a recent deployment, or a configuration change.
- Who and what is affected: which services, how many users, and what it means for the business.
- What to do next: remediation recommendations such as rolling back the last deployment or restarting the failing service.
- What it checked and ruled out: you can see how it reached its answer.
Returning to the example above, imagine that the underlying problem for that late-night alert was that a deployment to the payment service failed, bringing checkout down for 29 minutes. The SRE Agent
- traced the failure to that deployment, found a coding issue that had previously caused similar problems, and recommended a rollback.
- notified the payment team and prepared the revert for approval.
Why can you rely on what the SRE Agent finds?
Before the agent starts, Dynatrace Intelligence has already done the difficult part. Using its contextual understanding of your data, it already knows what broke: the payment service started failing right after a new deployment and took checkout down with it, and it knows which other services and users are affected. That’s also why the engineer gets one problem instead of a flood of alerts: Dynatrace groups events with the same cause.
The agent starts from that answer and builds on it rather than replacing it. It adds context and evidence, shows who’s affected, and recommends what to do. Because the investigation is anchored in the root cause Dynatrace found in your own data, you can trace every finding back to its evidence.
How do you put the SRE Agent to work?
The SRE Agent is embedded as an action within a workflow. Two parts work together to deliver a reliable outcome:
- The SRE Agent handles the unknown. It has a goal, investigates the problem, and brings SRE domain knowledge, plus a set of skills and tools it chooses to use to get there.
- The workflow handles the known. You define when it starts, which agent it calls with which context and instructions, and what happens with the result.
Add the Run agent action to an existing workflow, or start with our ready-made agentic workflow templates.
Every run follows the same loop:
- Trigger: a problem opens, an event fires, or a schedule runs. You define the trigger by problem type, impact, or criticality, for example only critical problems on customer-facing services.
- Understand: the agent starts from the root cause, evidence chain, and impact, then investigates further: it pulls related logs, events, deployments, and metrics for the affected services, follows Smartscape dependencies upstream and downstream as far as the evidence leads, checks for earlier problems with the same cause, and rules out what doesn’t fit.
- Triage: the rules you configured decide how urgent the problem is, based on its impact and criticality.
- Route: the workflow finds the responsible team in the ownership data.
- Act: the workflow takes the structured result and decides on the next steps.
What happens with these findings is up to you, and it can differ by type of problem:
Simple rules on the result decide which path to take. Users affected? Page the owner; otherwise, open a ticket. A known recurring issue? Attach the known fix for approval. In the example above, users were affected, and the agent found a recurring pattern, so the workflow notified the payment team and prepared a revert for approval. Every step in the workflow stays yours to adapt.
Beyond incident management: build your own agentic workflows
The SRE Agent investigates problems. With the Prompt agentic AI action, you can build agents for other jobs: you write the instructions, choose the data, and the tools available for the agent.
A few illustrative examples of workflows you can design, subject to available tools, data quality, permissions, and review controls:
- Spend matches what you actually use. An agent checks every week what your servers, clusters, and cloud resources are actually consuming and can generate a right-sizing analysis with estimated savings based on configured cost and usage data for teams to review.
- A report that tells you what matters. Instead of filling in the same template every week, the agent compares now with the past, picks out trends and changes, and writes about what’s worth knowing, including the surprise nobody thought to ask about.
- See what might happen next. An agent forecasts when a cluster will hit its limit or a disk will fill up, shows which services and users would be affected, and raises a warning while there’s still time to act, so teams can act before some capacity issues become incidents.
- Security that focuses on likely exposure. For a new threat alert, an agent can help identify which production systems are most likely to be exposed based on the data and detection scope available to it, and send its findings to your security team for review and validation.
How do you get started with the SRE Agent?
Trust in an agent comes from watching it work on your own problems, so start narrow and widen the scope once the annotations prove useful.
- Start with the services you own: use the SRE Agent to only work on your services by filtering affected entities and limiting the severity to critical or major. The next matching problem includes the agent’s root cause analysis, key findings, and recommendations on the problem details page.
- Check the analysis before you widen: compare the findings with what your team found during the incident. Adjust the prompt, if necessary, and edit the filter to investigate further problems.
- Send the result where your team works: add a Jira, ServiceNow, Slack, or Microsoft Teams task after the agent step, so the analysis lands in the ticket or channel the on-call engineer already watches.
- Put it to production: change the owner to a service account and keep an eye on run volume; you can further divide into individual, specialized workflows if necessary.
To experience the SRE Agent in action, you can also open an investigation in the Dynatrace Playground.
We’re eager to see how you use the SRE Agent. Share your experiences and use cases with us in the community.
