Checklist: availability status on public pages

I still reach for curl when someone says the site is down. Habit. Availability status on SlaySlop is the productized version of that instinct: it "checks whether the public site responds and records its state." If the origin will not answer, your meta description debate is cosplay.

Domain and infrastructure places this check beside DNS, redirects, ports, and friends. Monitoring as a product tracks uptime, incidents, scheduled scans, and site-health changes. Preflight availability is the on-demand cousin of that habit.

Outcome

Know whether the advertised public URL responds, what state was recorded at scan time, and whether you should stop triage until DNS/TLS/hosting owners unblock the path.

Boundaries

Read-only. Permission required. Not a pentest. Availability status is not a full multi-region SLA proof by itself. It does not replace Redirect chain mapping when hops are the real bug. It does not mean content quality is fine.

Checklist

1. Write down the exact hostname marketing shares.
2. Run Availability status (or open the finding) for that host.
3. If it fails, check DNS records and Redirect chain before blaming the app.
4. Confirm TLS/SSL rows if HTTPS is the advertised entry.
5. Only then open page-level SEO, performance, or accessibility findings.
6. After an incident, rescan availability before you declare recovery in Slack.
7. On paid plans, decide whether 24/7 uptime checks should watch the same URL going forward.

Compare smoke to scan evidence. Wrong host and wrong scheme waste hours.

Pitfalls

Interpreting LCP findings on a host that was failing half the scans. Trusting a status page vendor without recording your own public response state. Fixing a blog typo during an availability incident because it felt productive.

Related next step

Confirm response state first, then continue the rest of preflight. Availability status is in the checks catalog; monitoring product context lives under slayslop.com/products/monitoring.

After go-live

Preflight availability is necessary and insufficient. Once you ship, decide who watches uptime. Paid SlaySlop monitoring includes 24/7 uptime checks on the live site per the Lighthouse compare page contrast. If you decline that, name the alternate watcher. Unowned availability is how weekend outages become Monday surprises.

What responds means in practice

I treat a successful availability state as "the public entry returned a usable HTTP response from the scan's vantage point," not as proof every API behind the SPA works. Hydration can still throw. Console errors and Failed requests cover that layer. Availability is the door. UX runtime is the room.

When marketing shares both apex and www, check both or enforce a single redirect policy first. Split-brain availability, www fine, apex broken, creates tickets that argue past each other.

Document the expected scheme. Scanning http while customers type https (or the reverse) produces confusing state history. Align Redirect chain policy with the availability URL you monitor.

If you use status pages, link them in the runbook beside SlaySlop. Do not replace recorded scan state with a vendor emoji. After repair, keep the checklist item rescan availability explicit in the incident closeout so someone actually does it.

Done criteria

Availability preflight is done when the advertised URL responds in the recorded state you expect, redirect policy matches that URL, and someone is named to watch it after launch. Then open the rest of the checklist without arguing about content on a dead host.