
Modern AI-powered on-call and incident response platform. Trusted by @nvidia, @Replit, @Canva, @Grammarly, and more. Backed by @Google, @YCombinator.
Free trial 👉
Joined May 2020
- Tweets1.5K
- Following1
- Followers2.1K
- Likes1.5K
Who’s made your team better at reliability?
The engineer who fixes recurring problems. The calm voice during incidents. The mentor who helps everyone improve.
Nominate them for Rootly’s Reliability Top 50:
rootly.com/top50
Since moving from Opsgenie to Rootly, @pandadoc's stakeholders can ask the Rootly Agent for incident details instead of pulling responders into another conversation.
That means people get the context they need while engineers stay focused on resolving the incident. The Rootly AI Scribe captures what’s happening along the way, making communication easier during and after the response.
The move is also helping PandaDoc retire custom tooling its SRE team spent years maintaining. Slack agents, slash commands, and on-call payment exporters are giving way to Rootly’s native features and workflows.
PandaDoc finished its core setup in under a month. The benefits reach beyond the on-call rotation: easier access to information for stakeholders and less maintenance work for engineers.
PandaDoc’s story: root.ly/pandadoc
How much should you trust an AI agent during a production incident?
Join our SF panel with:
• @grinich (CEO, @WorkOS)
• Vishakha Sadhwani (Sr. Solutions Architect, @NVIDIA)
• @niallohiggins (Engineering Lead, @Replit)
• @SylvainKalache (Head of AI Labs @rootlyhq)
Agents on-call, human judgment & ownership.
Request to join: root.ly/agents-in-prod-sf
Dear Who Approved This?,
“Who’s accountable?” is the wrong question. Ask why the system let it happen.
That’s true when a person makes an outage worse, and it’s true when a script does. If automation turned a bad night into a worse one, the retro isn’t looking for someone to answer for it. It’s looking for the gap that let it run.
Automation is the better option for known problems with known fixes, like reverting a change that clearly caused errors or restarting a pod. Think of a sprinkler system. It puts out a certain kind of fire on its own, within limits someone set when it was installed. And it still sets off the alarm so the fire department comes.
So before your team automates more, decide three things.
1. Which actions it may take on its own.
2. When it has to stop and bring in a human.
3. And how it tells people what it did.
Anything outside that list needs a human to approve it, every time.
When it does go wrong, the review asks the same questions as always. Was that action on the list? Should it have been? What would have stopped it?
You don’t need to invite the script to the review. You need to set its limits before the incident, not during it.
—Ben On-Call
This #SFTechWeek by @a16z, Rootly brought together 1,200+ engineers building across the AI agent stack across three events.
🛠️ AI Agents Builder Night with @posthog, @convex, and @elastic
💡 Agents & APIs with @baseten, @getpostman, @supabase, and @promptingco
🌙 Twilight at Novela with Ampersand, Gauge, and @sentient_found: an evening for the people building enterprise agents and open AGI to connect beyond the presentations.
Thank you to every speaker, partner, and attendee who brought their questions, ideas, and curiosity. These photos capture a little of what made the week special.
See the recap: rootly.com/events
When you build an agentic platform, a lot of the engineering work lives in the moments between actions:
– Someone answers a question while the agent is preparing a reply.
– An approval arrives after the underlying message has changed.
– Two triggers fire close together.
Each action can make sense on its own. The hard part is reasoning about how they interact.
We run into this at Rootly building agents for incident response. Timing, changing context, and human decisions are all part of the system’s behavior. And they’re difficult to review in a static document.
So we made our engineering requirements document interactive.
Reviewers can replay a timeline, edit a source message, let an approval expire, or click Accept twice. They can explore the transitions and trace the explanation back to the code.
That introduces its own engineering challenge: the replay is a separate implementation, so it can drift. Keeping it aligned with production is part of maintaining the document.
For teams building agents, making behavior inspectable is becoming part of the engineering work.
Angelo Tomasco wrote about our approach and the tradeoffs: root.ly/dynamic-erds
Dear Formerly the Fastest,
As incident commander, knowing where to look and who to call has served you well. But the most valuable part of that experience is knowing what to do with what you find.
As AI takes on more of the correlation, first-pass triage, and timeline drafting, your job shifts toward judgment.
– Should we approve this rollback?
– Do we have enough confidence to tell customers we’ve recovered?
– Did that fix actually solve the problem, or did the alerts just stop?
Those decisions require someone who understands the system, the business, and the consequences of being wrong. Your experience gives you a basis for questioning a recommendation, including one that arrives quickly and sounds confident.
Expect your tooling to tell you what’s happening, why it matters, and what evidence supports its recommendation. You need enough context to make a decision—and to recognize when you need more.
That’s the role we’ve designed Rootly AI SRE to support: an incident sidekick that helps you spend more time on the decisions that need you.
Being first to open the right dashboard was useful. Knowing whether to trust what’s on it still is.
—Ben On-Call
On Saturday, I am co-hosting Paddles, Pints & Big Ideas alongside our friends at @WorkWeave, @rootlyhq, @tryreplicas, and @getcasco.
We are taking over SPIN San Francisco for an evening of table tennis, drinks, and good conversation with founders, CTOs, engineering leaders, and startup operators building the next wave of tech.
Channel your inner Marty Supreme on the table, grab a drink, and talk shop with other builders off the clock.
The RSVP link is in the comments below.
Writing down “A config change triggered the incident” is the easy part. But what else had to be true?
Which safeguards failed to catch it? What information was missing? What made the responder’s next decision seem reasonable?
Asking for a single root cause too early can narrow the investigation before the team understands what happened and steer the conversation toward blame.
As Ben McBratney, our Head of Incident Strategy, explains, AI can help reconstruct the incident. The team still needs to do the work of learning from it.
That’s why the Rootly Retrospective Template asks for contributing factors, plural. AI helps prepare the draft; responders question it, add context, and put together what they’ve learned.
A security finding is only useful if it reaches the people who can act on it.
@upwindsecurity's Lineup connects 100+ tools so that handoff actually happens.
Cloud security on one side, incident response on the other. Rootly is glad to be part of it.
.@AurorHQ is on a mission to reduce violent retail crime by 50% in five years. When their platform goes down, retail workers can get hurt.
That's why Nigel Wright, Director of Platform Engineering, called Rootly when he started building Auror's next stage of reliability.
Today, Auror uses Rootly to process every alert source, page the right responder, manage incidents quickly, and write the retrospective.
With Rootly, Auror's leadership has seen incidents close much faster across the board.
Learn more: root.ly/auror
Rootly retweeted
We put 100 cracked AI builders in one room to build agents on @Cloudflare at @rootlyhq . ⚡️
I’ve wanted to bring Cloudflare to Toronto for a hands on builder lab for a long time. We finally made it happen. ☁️🦞
The wild part? Cloudflare dropped the new CLEF/Jev model that SAME DAY and within hours, builders were already plugging it into agent workflows and demoing them live.
This is what ClawBuilders is about:
New tech drops → Tinker → Build → Demo that night.
First Cloudflare Toronto builder night. To many more! 🧡
@CloudflareDev @jjrichardtang
#ai #tech #toronto
.@CloudflareDev, Rootly, and Clawbuilders brought Toronto’s builder community together for an evening focused on building and deploying AI agents.
The tracks covered everything from AI pull request reviewers and multi-model code review to automated build logs and web QA agents.
The shared goal: take an idea, get it running, and have something to demo.
Thanks to everyone who joined, and to the organizers for bringing the community together!
Dear Afraid to Book the Flight,
If time off feels like a favor, you're just making it work.
A rotation that works doesn't run on goodwill. From the outside the two look the same, because incidents get handled either way. The difference shows up when someone tries to leave.
Try this test. Ask your team, "If two of us were out next week, who covers on-call?" If you have a plan, you're fine. If the answer is "we'd figure it out," you're making it work.
Four people is thin. When one person is on vacation and another gets sick, two people are covering everything. My rule of thumb is that a rotation needs at least five people before it has any slack. Google's SRE book says eight.
And no, the usual fixes don't solve this. Shift swaps are favors. Stipends don't add a name to the schedule. A quiet pager still means bringing your laptop to your kid's soccer game. If you can't hire, widen the rotation by merging with another team, adding a secondary, or taking low-impact services off the overnight pager.
Tired responders miss things. When they do, the fault lies with a system that assumed nobody would ever get tired, not with the person.
You should be able to book the flight.
—Ben On-Call





















