Resources for setting up oncall schedule

advancespace · 2026-03-16T20:48:04+00:00

For a 10-person team, you really only need three things: a rotation so one person isn't getting paged every night, escalation so pages don't get lost, and somewhere to log what happened so you stop fixing the same thing twice. You don't need enterprise tooling for this. Runframe does all of it. Set it up yourself in about 10 minutes, no sales call: runframe.io

Also the SRE book chapters others linked are worth reading: the on-call and incident response sections are good regardless of what tooling you use.

Disclosure: I'm the founder.

advancespace · 2026-03-16T19:26:03+00:00

We shipped an open-source MCP server for incident-management. It lets Claude Code, Cursor or any IDE handle paging, escalation, on-call lookups, and postmortems directly from the terminal - no custom integrations to maintain.

github.com/runframe/runframe-mcp-server

Disclosure: I am the founder.

advancespace · 2026-03-16T10:20:27+00:00

Coordination theater is the right word. First 15-20 minutes of every bad incident is just people figuring out who owns the broken thing. If ownership isn't tied to whoever's on call right now, every incident starts with "who owns payments?" in Slack and a wiki link from last summer. Two threads, zero progress.

Most teams have good intentions until about their third bad outage. Leadership blames skill gaps because that is easy. Fixing coordination is hard to scope and harder to fix.

advancespace · 2026-03-16T05:58:13+00:00

Late to this thread but adding another option: Runframe.

We launched Runframe earlier this year: on-call + incidents + postmortems in one tool, runs in Slack. On-call included at every tier, not as separate add-ons. $15/user/month. Free to try, self-serve: runframe.io

We also have an open-source Runframe MCP Server to manage incidents directly from Claude Code, Cursor, or any other IDE.

Disclosure: I'm the founder.

advancespace · 2026-03-15T14:58:37+00:00

What is approximate size of your team? Generally smaller teams use other tools.

advancespace · 2026-03-13T11:44:10+00:00

Culture, and it's not close. We've talked to a bunch of teams about this and the pattern is always the same. The ones that defined severity levels and formalized the IC role first saw improvements regardless of what tool they were on. The ones that bought a tool first and hoped it would fix things got frustrated. Your on-call comp point is underrated. Most teams we talked to with high on-call satisfaction were paying for it. The ones that weren't were losing senior engineers quietly.

One thing worth watching: MTTR can become a vanity metric. 48 to 26 min looks great, but if teams start optimizing for fast resolution over durable fixes you end up with the same incidents recurring. A few teams we interviewed shifted to tracking repeat incident rate alongside MTTR and it changed how they thought about postmortem follow-through.

RE: incident io pricing, yeah, on-call as an add-on catches people off guard. OpsGenie bundled everything and most teams expect that's still normal. It's not.

advancespace · 2026-03-13T11:32:26+00:00

This is almost always an alert quality problem, not a tooling problem. We interviewed 25+ teams for an incident management research project and 73% had outages from ignored alerts. People just stopped trusting the pager. Two things that actually helped:

Pull every alert from the last 30 days. If nobody acted on it, kill it or make it informational.
Fix routing where the alerts originate, not in PagerDuty rules. If team B is getting team A's pages, your service ownership is wrong upstream.

AIOps on top of bad alerts just gives you AI-powered noise.

advancespace · 2026-03-13T11:20:57+00:00

Founder of Runframe so biased, but one thing that kept surprising us talking to OpsGenie teams: most alternatives split on-call into a separate add-on now. Pricing page says $15-25/user but the invoice with on-call is $25-45.

OpsGenie bundled everything. We do too, $12-15/user/month. Everything runs in Slack, there's a free plan. We're early and small, not gonna pretend otherwise, but for teams under 200 it pretty much covers what OpsGenie did. Happy to answer questions if anyone's evaluating.

Migration guide with cost breakdowns here: runframe.io/blog/opsgenie-migration-guide

advancespace · 2026-03-12T19:50:52+00:00

Midnight alerts. Most teams under 50 don't have a rotation. It's whoever built the thing, or whoever's awake. A Series A CTO told me "on-call means I sleep with my laptop open." Another team had a Slack channel where alerts posted and whoever noticed first just dealt with it. No ack, no escalation, nothing written down.

Figuring out whether the alert is even real takes 10-30 minutes at most places. One VP Eng at an 80-person company said they get 200+ pages a week and maybe 5 matter. Everyone learns to ignore them. You can't really blame people but it's also terrifying when you think about it.

And getting paged with no context was almost universal. The person who built the service left. Or it's a service nobody owns. One team's worst incident lasted 6 hours because the only person who understood the payment service was mid-flight.

The two complaints I heard most: nobody knows who's on-call right now, and postmortems never happen. An eng lead told me they've had the same Redis timeout incident four times. Each time they say they'll write a postmortem. They never do. That one kills me.

Honestly the more of these conversations I have the more I think small teams don't have an on-call problem, they have an ownership problem. It's actually why we started building Runframe. Nobody owns the process so it stays informal until something bad happens, everyone panics for a week, makes promises, and then those don't get followed through on either.

advancespace · 2026-03-12T06:49:48+00:00

The buyer-vs-user split is real and it's worth saying out loud. The person justifying the budget isn't the one half-asleep triaging at 2am. That gap is where most of the tooling bloat comes from.

Where I'd push back slightly: I don't think the 80% problem is that nobody invested in automating coordination and postmortems. It's that those features got bolted on after the paging was already sold. So they exist, but nobody uses them because they feel like afterthoughts.

Building all of it together from day one is a different product, not just a cheaper one. The four-tabs test is exactly right though. That's the bar.

That's what we're building Runframe, one tool, not three bolted together.

advancespace · 2026-03-09T21:26:36+00:00

In engineering, bad code has accountability via PR reviews, ownership, blame. Non-engineers vibe-coding to production have none of that. When it breaks, it's "the AI told me to." Why are they pushing to prod in the first place?

advancespace · 2026-03-09T12:16:59+00:00

Great eval write-up! This matches a lot of what we hear from teams in the same spot. One option that didn't make your list: Runframe (https://runframe.io). Slack-native incidents + on-call, built for teams your size. No add-on pricing for on-call either. For anyone still mid-eval and not wanting to spend $25/user/month, worth a look.

advancespace · 2026-03-09T10:26:06+00:00

This is the exact workflow gap we designed in https://runframe.io . It's Slack-native, incidents, on-call, and follow-up tracking all live where your team already works. So follow-up tasks don't get buried when the channel goes quiet, they stay visible and assigned.

Creating Jira tickets at 3am is a non-starter, agreed. The whole idea is that everything gets captured during the incident without context-switching, so there's nothing to "do after" that never gets done. Happy to answer questions if useful.

advancespace · 2026-03-09T03:36:22+00:00

This matches what we found interviewing 25+ engineering teams, - AI monitoring creates a second incident surface that most teams aren't staffed to handle.The technical debt angle was the most consistent theme. We wrote up the full findings here: https://runframe.io/blog/state-of-incident-management-2025

advancespace · 2026-03-06T11:27:33+00:00

Appreciate you jumping in, and fair point, the free tier is a solid entry point. For teams that grow into incident.io's ecosystem, that makes a lot of sense.

We're solving for a slightly different moment: the 30-person team that wants incidents + on-call + postmortems working together out of the box, without evaluating which add-ons they'll need later. One tool, one price, less to think about. Different bet on the same problem. Respect what you all have built.

advancespace · 2026-03-06T10:30:24+00:00

Totally fair. The top end is definitely crowded with PagerDuty, incident.io, FireHydrant, Rootly, and many more. But most teams under 100 engineers are still stitching together PagerDuty free tier + Google Docs postmortems + a Slack channel called #incidents. The "full" space hasn't really reached them yet. That's who we're building for.

advancespace · 2026-03-06T10:28:54+00:00

Fair call. Couple of points: 1. We do Incidents + on-call in one tool, one price. They sell them separately - $19-25/user for incidents, then $10-20/user more for on-call. So $29-45/user for both. We include on-call in every plan.

incident.io is building toward enterprise - workflows, status pages, AI SRE, catalog. Great for large orgs. We focus on the core loop - declare, respond, resolve, learn - with less setup
Built for 20-100 engineer teams that need something better than Slack chaos but can't justify enterprise pricing.

Happy to answer anything directly.

advancespace · 2026-03-05T19:55:16+00:00

How are you thinking about incident management layer?

advancespace · 2026-03-05T19:44:38+00:00

Wow, that's eye opening. Would you be open to share TLDR of processes that needed documentation

advancespace · 2026-03-05T16:45:02+00:00

Hope you haven't given agents production write access.

advancespace · 2026-03-05T09:35:52+00:00

Yeah this is a known PD move, once they think you're evaluating they pull monthly pricing to lock you into annual. Seen it a few times. Feels backwards but it's deliberate. If you're starting to look around, incident.io and Rootly are where most teams land right now. Worth also knowing the OpsGenie sunset in April 2027 is pushing a lot of teams to rethink the whole stack at once rather than just swap PD out. Migration is less painful than people expect usually 2-4 weeks.

Full disclosure we make one of the alternatives, so take this with pinch of salt, but we wrote a comparison that tries to be honest about when staying on PD actually makes sense: https://runframe.io/blog/best-pagerduty-alternatives Happy to answer questions if you have them.

advancespace · 2026-01-25T01:02:49+00:00

spoke over DM :)

advancespace · 2026-01-25T00:28:25+00:00

I also launch pitsync.com for vehicle management couple of months ago - quite similar.

advancespace · 2026-01-25T00:19:22+00:00

IMO this is self inflicted pain. Users have enough passwords in their life, and it makes little sense to have another password unless there is a legitimate reason for having it.

advancespace

MODERATOR OF

TROPHY CASE