This blog post is part of PagerDuty’s ongoing series on how we’re helping customers navigate their journey towards autonomous operations. Read on to learn about how PD Automation Runner, now in Early Access, builds towards this vision.

Your on-call engineer gets paged for a critical alert on a self-hosted Kubernetes cluster. If this were a cloud-hosted service, Workflow Actions and the SRE Agent would already be working the problem: pulling logs, checking health, surfacing a fix. But for an on-prem tool, none of that fires. So the engineer does what Automation cannot: VPM into the network, find the right pod, read the logs line by line, and guess at a remediation, all while the clock on the incident keeps running. 

This isn’t just a Kubernetes problem. It’s true for Grafana, Prometheus, and every other on-prem or self-hosted tool your team uses. The fix would be simple if you could just open a port and let automation in, except no security team worth its salt signs off on that. So the tradeoff has always been binary – leave the automation gap in place or compromise your network posture to close it.

If you run on-call for anything on-prem or self-hosted, you know this wall. Today we’re closing it with PD Automation Runner.

Announcing PD Automation Runner

PD Automation Runner is a lightweight component you deploy inside your own infrastructure. It connects outbound to PagerDuty, so there’s nothing to open and nothing to allow-list. Once it’s running, Workflow Actions the SRE Agent can reach on-prem and self-hosted tools, starting with Kubernetes, right where they already live. The runner authenticates to the target system, executes the action locally, and returns the results to PagerDuty. 

What it unlocks

Once Workflow Actions can reach a system, SRE Agent can reason over what comes back. Say a pod hangs and starts eating memory. An Incident Workflow automatically pulls the affected pods and kicks off SRE Agent to analyze the logs, seconds after the incident fires, before anyone’s paged in just to go look. SRE Agent flags the unhealthy pod, summarizes the symptoms, and checks past incidents for what’s worked before. It recommends a fix. A responder approves it, the runner executes it directly on the cluster, and the pod comes back healthy.

Diagnosed, fixed, and closed out, without anyone touching a terminal, on infrastructure that used to sit entirely outside automation’s reach.

Secure by design

Nothing about closing this gap should mean loosening your network posture. The runner only ever initiates outbound connections, so there’s no inbound port, no IP allow list, and no standing access for PagerDuty into your environment. Authentication and execution both happen locally, inside your infrastructure, under your control while your security team’s posture doesn’t move. Your automation’s reach does.

The Flywheel Effect

Every incident your on-prem and self-hosted tools generate carries the same signal your cloud-hosted incidents always have. Until now, that signal stopped at the firewall. PD Automation Runner lets it flow: diagnostics come back, remediations get logged, and SRE Agent’s recommendations get sharper with every past incident it can draw on, cloud or on-prem alike.

That’s what autonomous operations looks like in practice. Not automation limited to wherever it’s easiest to reach, but automation that follows your infrastructure wherever it actually runs. Every incident PD Automation Runner resolves feeds the next recommendation, and the gap between cloud and on-prem response times keeps closing.

Try It Yourself

PD Automation Runner is in Early Access today for all PagerDuty Operations Cloud accounts, starting with Kubernetes actions. Support for more self-hosted tools, including Splunk, Grafana, and Prometheus, is on the way.

If your team runs Kubernetes and you’re still firefighting on-prem incidents by hand, talk to your PagerDuty account team about getting access or sign up for early access. Watch the full demo to see the PD Automation Runner in Action.