On-Call Tools for a Two-Person DevOps Shop

At a two- or three-person scale, the risk is not a disorganized incident channel, it is a missed page entirely because a phone was on silent, a notification got buried, or an app update quietly disabled alerts.

Whichever platform you pick, test its escalation path the way you would test a fire alarm: trigger a real test page at an inconvenient hour and confirm every fallback actually rings a phone. Workflow polish does not matter if the initial page never arrives in the first place.

A quick reliability test for a two-person rotation:

• Test the escalation path end to end, the way you would test a fire alarm, before a real incident happens.
• Confirm a page still reaches a phone that is on silent or that had an app update quietly disable alerts.
• Set a phone call or SMS fallback so a page doesn't depend on a Slack notification alone.
• Make the covering schedule visible to both partners, so each knows who is actually on call that week.

Both incident.io and PagerDuty may offer free or low-cost tiers for small teams, so check current plans, but paging reliability, not the dashboard, is what you are actually paying for as volume grows.

Before committing to either, price out what a real month looks like once you add a second client's on-call rotation or a second responder, since per-seat and per-service costs can jump faster than the sales page suggests at this scale, especially once you cross from one on-call schedule to two.

If you and your co-founder or partner are both already living in Slack all day, incident.io's slash-command channel and automatic timeline logging remove the one piece of friction a tiny team actually feels: having to write up what happened after the fact instead of during.

Its now-included on-call scheduling and phone paging can also mean you do not need a second subscription at all for a one- or two-rotation setup, which keeps your monthly tooling cost close to a single line item.

The moment a client is paying for genuine around-the-clock coverage, not best-effort response, the calculus shifts toward whichever tool has the more proven, most redundant paging infrastructure, because a missed alert is now a client-facing failure with real consequences.

PagerDuty's phone and SMS escalation across devices has the longer track record at that level, even if its interface asks more of you to set up than a Slack-native workflow does out of the box.

Say one of you is traveling for a week and reachable only by phone, not laptop. Whichever tool you use needs to page that person by call or SMS as the fallback, not assume a Slack notification will reach them, and the other partner needs visibility into who is actually covering that week without a shared calendar going stale.

This is the kind of small, specific scenario worth testing directly rather than assuming either platform handles it by default, since the default configuration in both tools tends to assume a more conventional office schedule.

The point where a small consultancy usually runs into trouble is adding a third or fourth engineer without revisiting the on-call setup that worked fine for two. A rotation built around two people trading nights informally does not scale cleanly to four, since the informal trust that made it work, each of you knowing the other would answer, does not transfer to a new hire the same way.

Treat crossing from two responders to three as the point where a documented, tool-enforced rotation stops being optional, even if the tool itself does not change.

When a prospective client asks a two-person shop how on-call works, they are rarely asking about tooling by name. They are asking a narrower question: if something breaks at 2am, does anyone actually notice, and how fast. A vague answer, we watch things closely, is the kind of thing that quietly loses a deal to a competitor who can describe an actual escalation path in one sentence.

Having a real answer, even a simple one, being on incident.io with phone paging configured for both partners and a tested fallback if one of you cannot be reached, is worth more in a sales conversation than either platform's specific feature list. Clients evaluating a small consultancy are looking for signs of operational maturity that do not depend on headcount, and a documented, testable on-call setup is one of the clearest signals available at this size.

Write that answer down before the next time a prospect asks, rather than improvising it in the moment. A short, specific description of your actual escalation path, reviewed and updated whenever your setup changes, does double duty: it is your internal documentation and your sales answer at the same time, and it costs nothing beyond the time it takes to write it down clearly.