The Scheduled Agents We Run, With the Prompts
How RunWhen uses RunWhen, part two: the scheduled Agents behind our vulnerability, certificate, PR review, environment health, storage and test-failure reports, with the prompts that drive them.
How RunWhen uses RunWhen, part two: the scheduled Agents behind our vulnerability, certificate, PR review, environment health, storage and test-failure reports, with the prompts that drive them.
Automating operations has no natural starting point, so most teams rank by intuition. We read a ticket estate instead. Three patterns show up again and again: hand-offs cost 5.6x, answering beats fixing four to one, and it is never one automation but thousands of small ones.
Giving an agent production access is the easy part. Making it safe is a set of design decisions: a reviewed skill registry, RBAC through scoped assistants, read-only by default, human-in-the-loop, the Agent-Runner pattern, and a complete audit trail. 500,000+ production hours, zero AI-caused incidents.
Agents shouldn’t hold credentials. The Agent-Runner pattern separates the reasoning plane from the execution plane. Blast radius gets scoped per network boundary, and agent load on your infrastructure becomes a setting.
A screenshots-first tour of how our own team — SRE, platform, developers, QA and the CEO — actually uses RunWhen Agents day to day. Daily newsletters instead of alerts, Slack root-cause answers, FinOps in minutes, and release readiness before standup.
Production troubleshooting is where agents get handed a haystack. Let code do the searching, and spend the model on judgment — with reviewed, shared skills instead of code improvised at runtime.
A new whitepaper by Kyle Forster on why agents with freeform skills will never be safe for production, and why the durable investment is a library of narrow, scoped safe skills that every later agent reuses. Free PDF download.
A TLS and false-positive alert story. Grafana provisioned datasources won’t reload a rotated cert until you nudge the YAML version integer forward. We forgot. A misleading alert led us back to it.
Joining a shared workspace mid-stream means walking into a room already full of context. /onboard-me is the tailored onboarding command our team wrote to give whoever just opened it the lay of the land — workspace identity, the services that matter, the conventions already in play, and a clear invitation to ask the next question.
You were out for a few days. A deploy went out, SHAs moved, a couple of things shipped. What actually changed? /dev-whats-changed answers the catching-up question with three ordered layers — code that’s live, commits since the last release, and only then a deeper dive — so the story leads with cause, not with infra alerts.
We built 22 slash commands for our own workspace. This series walks through the ones we use most, starting with how we decide whether to ship a release.
We run /mgr-release-readiness before every release. Here is what it checks, how it works, and what it told us today — with live results from our actual environment.
Drop into the same workspace our team uses every day. Real clusters, real agents, real remediations. No sandbox. About 45 minutes.
The RunWhen Platform MCP server connects your AI coding agent to your team’s workspace — locally over stdio or via RunWhen-hosted remote MCP on beta (Bearer token or OAuth browser sign-in where your client supports it) — so you can investigate infrastructure, create rules and commands, and author automation without leaving your editor.
This article shows how to improve alerting (dramatically) using Agentic AI and Automation.
David Tippett and Kyle Forster discuss AI assisted Search and it’s impact on development.
Explore how RunWhen’s AI Digital Assistants reduce costs and improve the outcome of application modernization projects.
See how Cautious Cathy, a RunWhen Digital Assistant, responds to a request to determine why a deployment will not roll out.
This blog post looks at some of the challenges with Kubernetes resource management, while highlighting some zero-cost approaches to reducing the frustration of resource management.
Read this short guide on best practices engaging the RunWhen team for a proof-of-concept.