Availability Status: what to verify before client handoff

I still reach for curl first when a client says the site is down. Headers, status, timing. Fine for a first look. Handoff needs more than my laptop and a hopeful refresh. It needs a recorded availability state someone else can trust after I step away.

SlaySlop defines Availability status in one line: it "checks whether the public site responds and records its state." Before I call a property handed off, I want that recording in place, not just a memory of a green tab.

What "done" means for availability

Done means:

• The site is verified in monitoring so ongoing checks attach to a property you control.
• A specific public URL is the probe target.
• A cadence is set for uptime probes.
• Incidents use the published rule: three failed checks open an incident, three successful checks close it.
• Someone knows who gets the email when that happens.
• The latest recorded state is Up, with timing you can show.

Monitoring copy on slayslop.com matches that shape: add and verify a site, set how often uptime probes and rescans run, keep incidents and history on a timeline, review what changed. I borrow that order for handoff because inventing a parallel process is how things get dropped.

Checklist I actually use

Handoff — availability
[ ] Ownership verified in SlaySlop for this site
[ ] Probe URL written in the portal (exact host + path)
[ ] Uptime interval set; client knows the interval
[ ] Alert recipients confirmed
[ ] Last probes show Up; no open incident
[ ] Sample incident rule explained (3 fails open / 3 successes close)
[ ] Separate quality scan attached (not confused with uptime)
[ ] DNS/TLS notes linked if relevant to prior outages

Yes, I left a typo in an earlier draft of this list once and shipped "SlaySlop" to a client. They noticed. Fix your strings. The product casing is SlaySlop.

# Last manual look before I trust the monitor
curl -sI -w "\nhttp_code=%{http_code} time=%{time_total}\n" "https://client-site.example/" | sed -n '1,25p'

If that fails, I do not hand off. I fix reachability first.

Map the probe to the promise

Agencies get burned by probing the wrong thing. The sales deck promised "the marketing site." The monitor hit an API subdomain that was never meant to be public-stable. Or the opposite: the homepage is a CMS behind a flaky third party, and every cache miss looks like an outage.

Write the probe URL in the portal. If you use a dedicated health path, say so. SlaySlop records state for the monitored URL; it will not telepathically know you meant a different host.

Separate uptime from quality in the packet

I keep two sections in the handoff note.

Section A — Availability: current status, last check, latency if shown, open incidents (hopefully none), interval, alert contacts. This is Availability status territory.

Section B — Quality: latest SlaySlop scan findings across security, SEO and AEO, performance, accessibility, and the rest. Scheduled rescans belong here as the plan for regressions after launch.

Mixing them produces the worst call: "monitoring said Up, so why is the SEO score bad?" Because Up only means the public site responded. It does not mean answer-engine readiness, headers, or LCP are fine. The product line is consistent on that split: uptime probes for down/up, scans for issues that block a safe launch.

Incidents without drama

Explain the three-and-three rule once. Three failures open. Three successes close. Emails on open and on recovery. Down and recovery events store timing and probe detail. That is enough for most clients.

What I do not do: redefine "down" in a slide to mean "felt slow." Slow is performance. Down is failed probes. If they want both, sell both: availability probes plus performance checks on rescans.

If an incident is open on handoff day, I do not soft-pedal it. Close the outage or document the open incident with owner and next check time. Handing over an unexplained red state is how you inherit a week of chat messages.

Plan and permission notes

Ongoing 24/7 uptime checks sit on paid monitoring, per SlaySlop compare language. If the client's plan does not include uptime, say so before they expect pages at midnight. The uptime UI itself has upgrade copy when probes are not on the plan. Better they hear it from you first.

Permission stays boring and necessary. Verify sites you manage. Do not point always-on probes at properties you are not allowed to monitor. Read-only scanning and acceptable-use rules still apply to the wider product; availability is not a loophole.

DNS and TLS belong in the appendix

When probes fail, the reason is often not the app code. Domain insights exist to put DNS, TLS, hosting, and mail beside uptime and security findings. Before handoff, I glance at certificate expiry windows and obvious DNS mistakes. I am not doing a full zone audit in every handoff. I am trying to avoid the outage that was predictable from an expiring cert.

A short narrative you can paste

Availability: SlaySlop probes https://client-site.example/ every N minutes.
State is recorded as Up/Down with latency. Three consecutive failures open
an incident and email ALERTS; three consecutive successes close it and email
again. As of HANDOFF_TIME (Africa/Cairo), status was Up with no open incident.
Quality: see attached scan report from SCAN_TIME for security, SEO/AEO,
performance, and accessibility findings. Uptime ≠ quality scan.

Fill the tokens. Keep the tone flat. Flat ages better than cheerful.

After you walk away

Handoff is not the end of availability. It is the start of their watch. Make sure they can open the uptime view, read incident history, and trigger or schedule rescans when something comes back from an outage. Launching is the easy part, as the monitoring headline says. Staying up is the job.

If you want that job on rails, verify the site in SlaySlop, set Availability status monitoring on the URL you mean, and put the checklist above in the portal before you send the "we're live" email.