Jordan: You promise your clients ninety-nine point nine percent uptime. You put it in the contract. You shake hands on it. And then — when something actually goes down — you open a spreadsheet, squint at your monitoring dashboard, try to remember what counts as an exclusion, and spend forty-five minutes doing arithmetic that determines whether you owe someone money.
Meanwhile, Twilio — a company with thousands of engineers — publishes an SLA that says "if we drop below ninety-nine point nine five percent availability, you get a ten percent credit, and here's the exact formula." AWS does the same thing for S3. Atlassian does it for their cloud products. These companies have codified the math. The thresholds, the brackets, the exclusion rules, the claim windows — it's all a lookup table.
And you — running a solo operation, serving maybe eight or twelve clients — you're doing this by hand. Every month. In a spreadsheet you built at midnight.
The contradiction is wild. The vendors who owe you credits have automated the process of making it hard to claim them. And you — the person who owes credits to your clients — haven't automated the process of calculating them honestly.
So today we're flipping that. The entire trust paperwork stack — credit math, the ledger, the status page updates, the incident comms — all of it runs from your audit logs without you touching a spreadsheet.
Jordan: If you have SLA commitments in your contracts and you're still calculating credits manually — or worse, waiting for a client to ask before you even check — you are one bad month away from a trust conversation you can't win. That's what today is about. This is Headcount Zero. I'm Jordan. And by the end of this episode you'll have a working SLA automation pipeline: audit logs feeding a credit calculator, a Notion ledger that tracks every client's uptime and credit status monthly, and a status page integration that drafts incident updates for you before your client even knows something's wrong.
Jordan: So here's the situation most solo operators are actually in. You wrote an SLA into your contract — maybe ninety-nine point five percent uptime, maybe ninety-nine point nine — because the client asked for it, or because you wanted to look professional. And then you never built the infrastructure to measure it. You don't have a system that computes your actual monthly uptime percentage. You don't have a ledger. You don't have a process for issuing credits when you miss. You just... hope you don't miss.
I had a client — a logistics company, one of my retainer accounts — come to me in February and say, "Hey, we had three outages last month. What does our SLA say we're owed?" And I had to go dig through Make execution logs, cross-reference timestamps with their contract, figure out which outages counted and which fell under the scheduled maintenance exclusion, and then do the math by hand. Took me about two hours. For one client. For one month.
And the worst part? The number I came back with was a forty-seven dollar credit. Two hours of my time for forty-seven dollars. But the trust cost of not having that answer ready — of making the client ask — that's the expensive part. That's the part that makes them wonder whether you're actually tracking what you promised.
Jordan: So step one is turning the SLA language in your contracts into a config table your automation can read. And the good news is, you don't have to invent the format. The big vendors have already done this work.
Twilio's API SLA — updated April twenty twenty-six — sets a monthly availability threshold of ninety-nine point nine five percent. Drop below that, you owe a ten percent credit on affected charges. One threshold, one bracket. Clean. They also exclude outages under five continuous minutes and any scheduled or emergency maintenance windows.
AWS S3 uses a tiered ladder. Below ninety-nine point nine but above ninety-nine? Ten percent credit. Below ninety-nine but above ninety-five? Twenty-five percent. Below ninety-five? Full credit — a hundred percent. They compute uptime from five-minute intervals, and you have to file your claim by the end of the second billing cycle after the incident month.
Atlassian's cloud SLA is similar to AWS but caps at fifty percent credit for the worst tier instead of a hundred.
Now — you're not Twilio. You're not AWS. But the structure is the same. You define your threshold, your brackets, your exclusion rules, and your claim window. Then you encode that as a config object — a JSON block or a Notion database row — and your automation reads it every time it runs the monthly calculation.
This is where most people get stuck, so let's slow down. The actual formula is straightforward. You take the total number of measurement windows in the month — if you're using five-minute intervals, that's roughly eight thousand seven hundred sixty windows in a thirty-day month. Subtract the error windows. Subtract any excluded windows — scheduled maintenance, outages under your minimum duration threshold. Divide by the total minus excluded. Multiply by a hundred. That's your monthly uptime percentage.
In a Make scenario, that's a single function module. Five lines of JavaScript. Total windows minus error windows minus excluded, divided by total minus excluded, times a hundred. Round to four decimal places. Done.
Jordan: Once you have the uptime number, you apply your credit ladder — the config table we just built — and write a row to your ledger. I use a Notion database for this, but a Google Sheet or CSV works fine. The row captures the client name, the service, the month, the uptime percentage, the credit percentage from the ladder, the billable amount, the calculated credit, the claim deadline, and links to your evidence — dashboard screenshots, log exports, whatever proves the number.
And here's the part that surprised me when I first built this. The ledger isn't just for months when you miss your SLA. You write a row every month. Ninety-nine point nine eight percent uptime, zero credit owed — that row still goes in. Because when a client asks "how have we been doing," you don't scramble. You send them a filtered view of their ledger. Twelve rows. Twelve months of proof that you're tracking what you promised.
That's the client proof problem solved at the infrastructure level. You're not building a dashboard. You're not building a portal. You're just writing one row per client per month and letting the data speak.
The scenario runs on the first of every month. It pulls your audit logs — if you set up lineage IDs back in episode six, those logs are already structured — aggregates the windows, computes uptime, applies the ladder, writes the ledger row, and sends you a summary email. Client name, uptime percentage, credit owed, claim deadline, evidence links. Takes roughly twelve minutes to set up the first time. After that it just runs.
Jordan: Okay. So the credit math runs monthly. But incidents don't wait for the end of the month. When something breaks at two PM on a Tuesday, your client needs to know — and they need to know before they discover it themselves.
And if you've ever been the person frantically typing a Slack message while simultaneously trying to fix the actual problem... you know that incident comms written under pressure are bad. They're vague. They're either too alarming or too dismissive. They don't include a next-update time, so the client sits there refreshing, wondering if you've disappeared.
The fix is templated comms triggered from your monitoring, but — and this is critical — defaulting to draft. Not auto-published. Draft.
Here's the flow. You set up an UptimeRobot monitor on your client's endpoint. You add a webhook alert contact — that's a POST request to your Make or n8n webhook URL every time the monitor status changes. When UptimeRobot fires that webhook, your automation parses the payload — monitor ID, alert type, duration — and creates an incident on your status page. Statuspage and Instatus both expose APIs for this. Statuspage is a POST to their incidents endpoint with your page ID. Instatus is the same pattern, different URL. Both let you set the incident to unpublished and notifications to off.
So what actually happens is: your monitor detects a problem, your automation creates a draft incident with a pre-filled template — the service name, the scope of impact, what you're investigating, and a promised next-update time — and then it pings you on Slack or email. You review the draft. If it's real, you hit publish. If the monitor recovered in three minutes and it was a blip, you delete the draft and move on.
The template is the part that saves you. Atlassian's incident management guides have been saying this for years — use pre-approved templates, always include a next-update time, communicate across multiple channels. PagerDuty built reusable status update templates with Liquid variables and a "time till next update" field directly into their product. These aren't novel ideas. They're just ideas that solo operators never implement because they think incident comms is something only big teams need.
Your template has three states. Investigating: here's what's affected, here's what we're doing, next update by this time. Identified: here's the cause, here's the mitigation, here's your workaround if there is one. Resolved: service recovered, here's the impact window, here's the post-mortem link if applicable. Three templates. You write them once. Your automation fills in the variables.
Jordan: Now — I can already hear the objection. "Jordan, if the automation can create the incident and fill in the template, why not just auto-publish it? Why add the human step?"
Fair instinct. And honestly, I tried it. For about two weeks. Here's what happened. UptimeRobot flagged a brief connectivity blip — lasted maybe ninety seconds — and my automation dutifully published an incident to my status page saying we were investigating elevated errors. By the time I saw the notification, the service had already recovered. But the incident was live. My client saw it. Their ops team saw it. And now I'm writing a post-mortem for a ninety-second blip that affected zero actual transactions.
SRE teams at much larger companies have learned this the hard way too. There's a whole thread on the SRE subreddit about this — practitioners warning that raw-alert auto-publish is noisy and often wrong in the first ten minutes. The consensus is draft first, approve before publishing.
So the guardrails I run now are simple. First, the automation only creates a draft incident when at least two of three signals agree for five minutes or longer — external monitor down, error-rate spike in my first-party logs, and synthetic healthcheck failing. One signal alone doesn't trigger anything. Second, if the monitor recovers in under eight minutes, the draft auto-resolves silently. No publish, no notification, no noise. Third, I cap update cadence at every thirty minutes and always set a "next update by" timestamp so the client knows when to expect the next word from me.
The result is that my clients see fewer incidents — but every incident they see is real, well-described, and comes with a timeline. That's the difference between automation that builds trust and automation that erodes it.
Jordan: So the full pipeline looks like this. UptimeRobot monitors your endpoints and fires webhooks to your Make or n8n scenario. That scenario handles two jobs. Job one is the monthly credit calculation — aggregate logs, compute uptime, apply the credit ladder, write the ledger row, email you the summary with claim deadlines. Job two is incident response — parse the alert, check your multi-signal gate, create a draft incident via the Statuspage or Instatus API with your pre-filled template, and notify you to review.
The SLA Credit plus Comms Kit on the resources page has the exact scenario specs for both Make and n8n — the webhook setup, the JavaScript functions, the API payloads for Statuspage and Instatus, the Notion ledger schema, and all three incident comms templates. You can copy the configs and swap in your own client names, thresholds, and API keys.
Total cost for the monitoring layer is zero if you're on UptimeRobot's free tier — you get up to fifty monitors. Statuspage starts at twenty-nine dollars a month. Instatus has a free tier. The Make or n8n scenario burns maybe two hundred operations a month per client on the credit calculation side, and the incident flow only fires when something actually breaks.
Jordan: So let me bring this back to where we started. The contradiction. Vendors like Twilio and AWS have turned their SLA obligations into lookup tables and automated claim processes — designed, frankly, to make it just annoying enough that most people don't bother filing. And meanwhile, you — the solo operator who actually wants to be honest with your clients — you've been doing the same math by hand in a spreadsheet that nobody audits.
That's over now. You have the credit ladder config. You have the formula. You have the ledger that writes itself on the first of every month. And you have incident comms that draft themselves from templates before your client even thinks to ask what's happening.
Here's what I want you to do this week. Pick one client — the one with the most clearly defined SLA in their contract. Set up the credit ladder config for that one client. Run the calculation against last month's logs. Write the first ledger row. That's it. One client, one month, one row. Once you see how fast it runs, you'll wire up the rest.
That's the episode. I'm Jordan. This is Headcount Zero. I'll see you on Friday.