Bug Triage and On-Call for a Small SaaS Team

Bug triage and on-call are the two disciplines that decide whether a small SaaS team stays sane or burns out in year one. Without a clear system, every bug becomes a fire drill, every alert wakes up the wrong person, and engineers start ignoring notifications because there are too many of them. The good news is that the systems that work at a five-person startup are the same as the ones that work at a fifty-person company, just simpler. This piece walks through the exact triage and on-call playbook I use inside QwiklyLaunch 45-day launches and continue with after handoff. Severity levels, rotation design, tooling choices, escalation paths, and the burnout prevention rules that keep the team functional. If you set this up right in the first month, you will sleep better, ship faster, and lose fewer engineers to churn.

Severity Levels: Four Tiers, Not Ten

Every bug and incident should be classified into one of four severity levels. Sev 1 is a full outage or data loss affecting all users. Sev 2 is a degraded service or a feature down affecting many users. Sev 3 is a bug affecting some users with a workaround available. Sev 4 is a cosmetic issue or edge case with no workaround needed.

Keep it to four levels because more than four produces disagreements about which bucket a bug belongs in, and disagreements slow triage. Write the definitions in a doc that everyone can see, use them in every incident, and enforce them in the ticket system. If a bug does not fit cleanly, default to the lower severity, because over-classifying leads to alert fatigue.

Response Time Expectations

Sev 1 requires an engineer on the incident within fifteen minutes, 24/7. Sev 2 requires response within one hour during business hours, four hours off-hours. Sev 3 goes into the sprint backlog and ships within two weeks. Sev 4 goes into a bugs-of-shame list and gets addressed opportunistically during related feature work.

These expectations are for a small team. Enterprise SLA commitments may require faster response times for Sev 1 and Sev 2. If you have contracts, match your internal expectations to the tightest customer SLA, plus a fifteen-minute buffer for detection and page.

The On-Call Rotation: Design For Sustainability

A small team of three to five engineers should run a weekly rotation with one primary and one secondary. The primary responds first, the secondary steps in if the primary does not acknowledge within ten minutes. Do not run daily rotations, they produce too much context switching and prevent engineers from doing deep work. Do not run monthly rotations, they concentrate too much stress on one person.

Rotate on Mondays at 10 AM local time. Do not rotate at midnight, because the outgoing engineer wants sleep and the incoming engineer needs coffee. Send a Slack reminder the Friday before, so the incoming engineer can adjust their week. Use a tool like PagerDuty, Opsgenie, or Better Stack to manage the schedule and paging.

The Two-Person Minimum

Never run on-call with only one person available. The primary needs a backup, the backup needs vacation coverage, and one-person rotations produce burnout within three months. If your team is under three engineers, either share on-call with a partner firm or lower your SLA commitments to business-hours only until you can hire.

Compensation And Recognition

On-call is real work and should be compensated. Options include a flat weekly stipend of $200 to $500, a day of comp time per on-call week, or a percentage salary uplift for engineers who volunteer. Uncompensated on-call is the fastest way to lose senior engineers. Track how often each person is paged and make the burden visible to the team.

Alerting: Signal Over Noise

The single biggest cause of on-call burnout is alert fatigue. If an engineer gets three alerts a night and two of them are false alarms, they will stop trusting the alerts and miss the real one. Alerts should page a human only when a human needs to act. Everything else goes to a Slack channel or a dashboard.

Start with three alerts: error rate above baseline, response time above SLA, and database unavailable. Add more only when a real incident happened that a new alert would have caught earlier. Every quarter, review the alert list and delete anything that has not fired in three months or has fired without action.

The Alert Runbook

Every paging alert should link to a runbook that explains what to check, how to mitigate, and who to escalate to. Runbooks reduce mean time to recovery by fifty to seventy percent for known incident patterns. Keep them in the same repo as your code so they get updated with the system. Our devops and cloud practice builds runbooks as part of every launch.

Triage Meetings: Once A Week, Thirty Minutes

Run a weekly triage meeting where the on-call engineer, the tech lead, and the product owner review every bug filed in the last week. Assign severity, owner, and target sprint. Anything Sev 3 or 4 that has been open more than four weeks either gets closed as won't fix or gets escalated to a real priority.

Keep the meeting to thirty minutes. If triage takes longer, you are either accumulating bugs faster than you can process them, or you are discussing solutions instead of classifying. Move solution discussions to a separate meeting or async thread. Triage is about routing, not problem solving.

Bug Aging And Bankruptcy

Every quarter, do a bug bankruptcy sweep. Close any Sev 3 or Sev 4 bug open longer than 120 days that has not been touched. This is painful the first time and freeing every time after. If a bug matters, someone will file it again. If they do not, it did not matter. This discipline keeps the backlog honest and prevents the psychological weight of a thousand-bug backlog.

Tooling: The Minimum Viable Stack

The minimum viable on-call stack for a small SaaS is: Sentry or Rollbar for error tracking, PagerDuty or Better Stack for paging, Linear or Jira for the bug backlog, Slack for incident coordination, and Notion or a git repo for runbooks. Total cost around $300 to $800 a month for a five-person team.

Add a status page like Instatus or Statuspage once you have paying customers. Customers deserve visibility into incidents and a public status page saves you dozens of support tickets during any outage. Update the status page as part of the incident response runbook, not as an afterthought.

Observability Beyond Errors

Error tracking catches crashes but not degradations. Add basic performance monitoring through Datadog, New Relic, or a lighter tool like Vercel Analytics. Track p50, p95, and p99 response times on your top ten endpoints, and alert when p95 doubles from its baseline. Degradations that do not throw errors are often more important than the errors themselves.

Incident Response: The Five Steps

When a Sev 1 or Sev 2 fires, follow five steps. First, acknowledge the page and post in the incident Slack channel. Second, assess impact and update the status page if customer-facing. Third, mitigate through rollback, feature flag, or hotfix. Fourth, communicate to affected customers when resolved. Fifth, write a postmortem within 48 hours.

The postmortem is the most important step because it is where the team learns. Keep postmortems blameless, focus on process and system gaps, and include concrete action items with owners and deadlines. Ship the action items within two weeks or the postmortem was theater. Our software development writeups cover postmortem templates in detail.

Preventing Burnout: The Cultural Rules

Burnout kills small teams faster than any technical debt. Enforce three cultural rules. First, no one is on call more than one week in four. Second, on-call engineers do not have feature deliverables that week, on-call is the full-time job. Third, an engineer paged after 11 PM starts the next day no earlier than 11 AM.

These rules seem expensive but they are cheaper than replacing a burned-out senior engineer, which costs $50,000 to $150,000 in recruiting, ramp, and lost velocity. Protect your people or they will leave, and small teams cannot afford turnover in year one. If you want a QwiklyLaunch team to set up your bug triage and on-call system as part of a fixed 45-day launch, reach out through the contact page. You can also see the incident response processes we run for live clients in our projects gallery.