What evidence should back an availability status finding

"Site seems down" is not evidence. What an attacker, or a customer, hits is a concrete URL and a concrete response. SlaySlop's Availability status check "checks whether the public site responds and records its state." The packet should make that state legible.

Outcome

From the evidence you can say which public URL was tested, what response state was recorded, and when. That is enough to page the right owner and enough to compare after recovery.

Boundaries

Read-only observation. Permission required. Not a pentest. Not a substitute for provider status pages, not a full synthetic multi-city mesh unless your monitoring plan says so. Do not invent outage narratives the state does not support.

Redirect chain, DNS records, TLS, and open ports may explain the state. They are separate checks. Link them; do not overwrite availability evidence with guesses.

Packet shape

check: Availability status
glossary: https://slayslop.com/glossary/availability-status
definition: checks whether the public site responds and records its state
target_url: https://www.example.com/
observed_state: <from scan evidence>
scanned_at: <timestamp from report>
related_checks_to_open:
 - Redirect chain
 - DNS records
 - SSL certificate / TLS configuration
non_claims:
 - not a pentest
 - not proof of root cause without correlated evidence

Permissioned smoke while you triage:

curl -sI --max-time 10 "https://www.example.com/" | sed -n '1,25p'

If curl succeeds and the scan recorded failure (or the reverse), write both down. Timing and edge location differences happen. Do not silently discard the scan state.

Good vs bad evidence

Good: "At 14:02 UTC+3, https://www.example.com/ recorded non-success response state in Availability status; apex http redirects to a host returning 502." Bad: "Client said it was slow." Bad: a marketing uptime percentage with no URL.

When the state clears, keep the historical finding in the incident note. Deleting history makes the next outage feel brand new.

Pitfalls

Paging developers before DNS. Blaming application code for a redirect loop. Pasting availability evidence into a security questionnaire as if it were a pentest result. Mixing Client-side secrets drama into an availability bridge call.

Related next step

Attach URL, state, and time. Correlate with domain checks. Rescan after repair. Capture the first packet with a permissioned run on slayslop.com if you do not already have the finding open.

Correlation notes worth keeping

When Availability status fails and Redirect chain shows a loop, lead with the loop in the incident channel. When DNS records point at an old load balancer, lead with DNS. When TLS expires, lead with the certificate row. Availability evidence is the alarm. Correlation is the diagnosis. Keep both in the write-up so the next on-call person is not guessing.

Sharing evidence without spreading panic

Portal readers escalate emotionally. Lead with URL, state, and timestamp. Put hypotheses under a separate "working notes" field. If the state is degraded rather than fully down, say degraded. Overstating outages burns credibility the next time Availability status fires at 3am.

For agencies, attach the evidence to the client-facing note only after you know which host they advertise. Showing a failed preview URL during a production incident is how you create a second problem on the call.

Closing the loop with monitoring

If the client is on a plan with 24/7 uptime checks, connect the incident note to that monitor after recovery so the next failure pages the same owners. Availability status evidence from an on-demand scan and uptime history from monitoring tell one story when they share the same URL. When they do not share a URL, fix that configuration before the next outage review.