Jordan: Every proposal I send includes an SLA section. Ninety-nine point nine percent uptime. Twenty-minute update cadence during incidents. Credits calculated automatically if I miss the target. It looks professional. It sounds enterprise. Clients love it.
And for the first eight months of my business, every word of that section was a lie.
Not intentionally. I believed I could deliver ninety-nine point nine. I probably was delivering it. But if you'd asked me to prove it — to show you the incident timeline, the client notifications, the credit math — I had nothing. No status page. No runbook. No alert that told me something was down before a client Slacked me at eleven PM saying "hey, the dashboard isn't loading."
The contradiction hit me during a renewal call. Client asks, "We had that outage in March — how long was it actually down?" And I'm scrolling through Slack messages trying to reconstruct a timeline from memory. Forty-five minutes of silence on my end while the client waited for an answer I should have had in ten seconds.
That's the gap. You can write an SLA in fifteen minutes. You can promise the moon. But the distance between promising an SLA and operating one — actually having the infrastructure to detect, communicate, calculate, and close — that distance is where solo operators lose enterprise clients.
Today we're closing that distance. The whole loop. One afternoon.
Jordan: If you're running production automations for clients and you don't have a closed loop from alert to status update to credit calculation, you are one bad incident away from a renewal conversation where the client has better records than you do. And you will lose that conversation. This is the season two finale of Headcount Zero. I'm Jordan. And we're wrapping the solo ops season by building the one system that ties everything together — SLA monitoring automation. Your monitor fires, a draft status update appears for your approval, Slack enforces your update cadence, and when the incident closes, the credit math runs itself. By the end of this episode, you'll have the architecture for all of it.
Jordan: Before we build anything — a misconception I need to kill. People set up a Statuspage and think they've set up monitoring. They haven't. Atlassian says this explicitly in their own docs. Statuspage is a communication tool. It does not check whether your endpoints are up. It doesn't ping your webhooks. It knows nothing about your infrastructure unless something tells it. The loop starts upstream — with your monitor. Uptrends, Datadog, UptimeRobot, whatever you're already running. The monitor detects the problem. Everything after that is communication and math.
So here's the architecture. Five pieces, one loop. Monitor detects an issue. Your automation drafts a Statuspage incident — drafts, not publishes. That draft lands in a Slack channel for your review. You approve it, it goes public, and Slack starts enforcing your update cadence. When the incident resolves, the metadata feeds a credit calculator that tells you exactly what you owe. A post-incident report captures the timeline for your records and your client's.
That's the loop. Now let's wire it.
Jordan: The Statuspage API. You need an API key — create it from the API info screen in your account. Important note: as of June thirtieth, Atlassian is deprecating API keys passed as query parameters. Send your key in the Authorization header. Format is Authorization colon OAuth, then your key. Store it in your secrets manager — not hardcoded in a scenario.
The endpoint you care about is POST to slash v1 slash pages slash your page ID slash incidents. The payload is a JSON object with an incident key containing name — the title your clients see — status, which starts as "investigating," impact override — none, minor, major, or critical — component IDs mapping to the services on your page, and body — the public message.
And the critical field. Deliver notifications — set it to false. When you create the incident, you do not want it blasting emails and SMS to subscribers automatically. You want a draft. A private draft you review before anyone sees it.
The instinct is to automate end to end. Monitor fires, incident publishes, subscribers get notified. Fully hands-off. That instinct will burn you. PagerDuty's stakeholder communications guide makes this point — raw alerts often lack context. A monitor might fire because of a thirty-second blip that self-resolves. If that blip auto-publishes a "major outage" notification, you've created a trust problem out of a non-event.
I learned this the hard way. Early version of this loop auto-published everything. One Saturday morning, a DNS propagation delay triggered my monitor. Sixty seconds later it resolved. But three clients had already received an email saying "major outage — investigating." I spent the rest of my Saturday explaining that nothing was actually wrong.
So the pattern is human-in-the-loop for the first ten to fifteen minutes. Automation creates the incident with notifications off, posts the draft to a private Slack channel. You read it. If it's real, you react with a checkmark emoji, and a second automation flips deliver notifications to true. If it's a false alarm, you dismiss it and the public page never changes.
Jordan: Once an incident is live, you need to keep talking. Atlassian's incident communication best practices recommend updates every twenty to thirty minutes until resolution. Not "when you have something new." Every twenty to thirty minutes. Because silence during an outage is louder than bad news. A message that says "still investigating, we've narrowed it to the database connection pool, next update in twenty minutes" — that's worth more than a fix that arrives silently.
But when you're solo and actually debugging the problem, remembering to post a public update every twenty minutes is the last thing on your mind. So Slack does it for you. Simplest version — slash remind, the channel name, "post a public update — what changed plus next ETA," every twenty minutes. When the incident resolves, slash remind list, mark it complete. Fifteen seconds to set up. If you want something more structured, Slack's Workflow Builder lets you create a shortcut that posts a pinned incident template and loops a reminder every twenty or thirty minutes until someone posts a resolve command.
It's not sophisticated. It's a timer and a nudge. But it's the difference between a client who trusts your process and a client who's refreshing your status page wondering if anyone's home.
Jordan: Now — what actually goes in your SLA. You need two numbers and one cadence. Time to First Response — how quickly you acknowledge the problem. Zendesk, Freshdesk, Intercom — all the major help desk platforms formalize this metric. For a solo consultant during business hours, fifteen to thirty minutes is credible. Next Response Time — how long between updates once the incident is open. Twenty to thirty minutes, matching the Atlassian recommendation. And you can specify a different cadence for off-hours — "best effort, updates within sixty minutes" is honest and reasonable. Don't promise what you can't automate.
Uptime target. Ninety-nine point nine percent monthly sounds aggressive, but a thirty-day month has about forty-three thousand minutes. Ninety-nine point nine means you're allowed forty-three minutes of downtime. If you're building on providers like Vercel or DigitalOcean who themselves commit to ninety-nine point nine nine — forty-three minutes is achievable. Not easy. But achievable.
Now — the part that makes this loop pay for itself. When an incident resolves, you have metadata. Start time, end time, duration, affected components, severity. That's everything you need to compute what you owe.
Two models work. Uptime bands — this is what Vercel uses. Monthly uptime between ninety-nine point one and ninety-nine point nine eight percent, ten percent credit. Between ninety-five and ninety-nine, twenty-five percent. Below ninety-five, fifty percent. Clean tiers. Or simpler — per-interval credits. Five percent for every thirty minutes of downtime, capped at fifty percent. Sixty-five minutes down means three intervals times five percent — fifteen percent credit. On a two-thousand-dollar retainer, that's three hundred dollars.
And here's why automating this matters. You don't want to be the person who calculates credits only when a client asks. You want to send a credit notice proactively, before the client even thinks to check. That's a trust signal agencies with ten people can't match — their process requires three approvals and a finance review. Yours requires a formula and an email template triggered when an incident closes with downtime greater than zero.
Jordan: Okay. Now I need to be honest about something. Because everything I just described sounds clean. Monitor fires, draft appears, you approve, cadence runs, credits calculate. Neat loop. Ship it.
But I've been running this system for almost a year now, and the failure modes are real. They're not hypothetical.
The first one is alert noise. If your monitor is too sensitive — and most default configurations are — you'll get draft incidents for things that aren't incidents. A thirty-second timeout. A single failed health check that passes on retry. A CDN edge node hiccup in a region none of your clients use. Each one creates a Slack message you have to evaluate. And when you're getting four or five of those a week, you start ignoring them. That's the worst outcome — you've built a system that trains you to dismiss alerts.
I hit this in month two. My UptimeRobot checks were set to one-minute intervals with a single-failure trigger. I was getting draft incidents for blips that resolved before I could even open Slack. So I'd dismiss, dismiss, dismiss. And then one Tuesday afternoon, I dismissed a real one. Client's webhook endpoint was actually down. I caught it forty minutes later because a client messaged me — which is exactly the scenario this whole system is supposed to prevent.
The second failure mode is cadence fatigue. You set up the twenty-minute reminders, and during a real incident that lasts two hours, you're getting pinged six times. By the fourth reminder, you're posting "still investigating, no change" — which is exactly what PagerDuty warns against. Empty updates erode trust faster than silence does, because now the client is reading updates that say nothing and wondering if you're actually working the problem.
And the third one... the third one is harder to talk about. It's the false confidence problem. You build this loop, you put SLA commitments in your proposals, and you start promising things based on the assumption that the system works. But the system is only as good as your monitor configuration, your approval discipline, and your willingness to actually send credits when you owe them. I had a month where my monitor missed a degradation — not a full outage, a slow response time issue — and my Statuspage showed green the entire time. Client noticed before I did. Again.
So here's what I actually learned. The guardrails matter more than the loop. First — tune your monitor before you connect it to anything. Require two consecutive failures across two check locations before an alert fires. That alone killed eighty percent of my false drafts. Second — deduplication. Your automation checks whether an incident is already open for the same component before creating a new one. Simple lookup. Third — the cadence reminders are reminders, not auto-posters. They nudge you. You still write the update. And if nothing has changed, you post a shorter note with a fresh ETA — not "no change." PagerDuty's guidance here is direct: set expectations for the next update, but never repeat empty messages.
The philosophy is human-in-the-loop. The automation handles plumbing — creating drafts, enforcing timing, computing math. You handle judgment — is this real, what should I tell the client, is this update worth sending. That split is what makes it sustainable solo. You're not replacing yourself. You're giving yourself a system that remembers the things you forget when you're knee-deep in a production issue at two AM.
And if you want the copy-paste version of all of this — the Notion ops manual, the API snippets with the approval gate, the Slack cadence workflow, the credit calculator with both models, and the post-incident report template — grab the Solo SLA Loop Starter Kit on the Resources page.
Jordan: So — remember that renewal call I mentioned at the top? Client asks how long the March outage lasted, and I'm digging through Slack messages like an archaeologist. That call is what started all of this. And the version of me on the other end of that call today has a very different answer. I pull up the incident record. Forty-seven minutes. Sev-two. Three public updates during the event. Credit of seven point five percent already applied to last month's invoice. Post-incident report with the root cause and the fix.
That answer takes ten seconds. And it changes the entire dynamic. You're not defending yourself. You're demonstrating a process. The client doesn't leave that call worried about reliability. They leave thinking "this person runs a tighter operation than vendors ten times their size."
That's what SLA monitoring automation actually gives you. Not just compliance. Credibility.
This is the last episode of season two. We've spent twelve episodes building the operational backbone of a solo practice — from prompt regression gates to platform migrations to trust centers to this, the incident loop that ties it all together. If you've been building along with me, you have infrastructure now that most small agencies don't. Use it.
One thing to do this week. Just one. Set up the Statuspage API connection and the Slack approval channel. Don't build the whole loop yet. Just get the draft incident flowing to Slack so that the next time your monitor fires, you see it in a channel instead of in a panicked client message. That's the foundation. Everything else layers on top.
I'm Jordan. This is Headcount Zero. Season three starts in two weeks. I'll see you then.