How SlaySlop checks Availability Status

Client calls go sideways when "we monitor the site" means three different things to three people. For SlaySlop, Availability status has a published definition: it "checks whether the public site responds and records its state." The monitoring product turns that into probes, history, and incidents you can open during launch week without improvising.

What you get out of the check

You get an ongoing answer for a verified site: is the public URL answering, how long did the probe take, and has an incident opened or closed? SlaySlop describes monitoring as tracking uptime, incidents, scheduled scans, and site-health changes. Uptime probes and scheduled rescans tell you when something goes down or a fixed problem comes back.

That is the outcome agencies actually need after handoff. Not a vibes-based "it looked fine on my laptop."

How the workflow is supposed to run

The monitoring HowTo on slayslop.com is linear on purpose:

1. Add and verify a site — ownership verification connects ongoing checks to a site you control.
2. Set the cadence — choose how often uptime probes and rescans run.
3. Changes get recorded — incidents, scan history, and score changes build a timeline.
4. Review what changed — open the affected report and compare to the last clean run.

Availability status lives inside that loop. Probes produce the availability timeline. Rescans cover the quality side after the origin is healthy again.

Probe behavior you can explain on a call

Always-on uptime copy on the product site states the rules in plain language. Availability probes run around the clock at the interval you choose. Three failed checks open an incident. Three successful checks close it. Down and recovery events are stored with timing and probe detail. An email goes out when repeated failures open an incident, and another when the site comes back.

That "three and three" rule is the methodology hint repeated in the uptime UI strings. It exists so a single blip does not become theater, and so recovery is as explicit as failure.

Dashboard language you may see while monitoring is active includes availability label and name for the current probe, Up and Down, response time, last check, last latency, open incident versus none, and consecutive failure counts. If live status is unavailable, the UI says so instead of inventing a green badge.

# Example incident narrative for a status note (illustrative)
site: yourapp.example
rule: 3 consecutive failures open / 3 consecutive successes close
09:14  probe fail
09:17  probe fail
09:20  probe fail -> incident opened -> email sent
09:35  probe ok
09:38  probe ok
09:41  probe ok -> incident closed -> email sent

Where Availability status sits in the catalog

On the checks catalog, Availability status is listed under Domain and infrastructure: checks whether the public site responds and records its state. Neighboring infrastructure checks cover themes like unexpected public service exposure and public subdomain signals. Domain insights product copy ties DNS, TLS, hosting, and mail together so infrastructure evidence can sit beside security and uptime findings.

Do not tell a client that an availability probe "did a security audit." It recorded reachability. Separate scheduled rescans still run the broader quality categories when you ask for them.

Boundaries that keep you out of trouble

Permission and verification: ongoing monitoring attaches after you verify a site you control. One-off public teaser scans are a different lane from 24/7 probes. Compare materials on SlaySlop note that paid plans include 24/7 uptime checks on the live site. If a plan does not include uptime, the product tells you uptime is not on your plan and prompts an upgrade for probes and incident history. Say that early in a proposal so launch week is not a surprise.

Read-only posture still applies to scanning. Probes request a public URL; they are not a license to attack a property you do not manage.

Availability is also not your full handoff packet. Security headers, secrets, SEO and AEO, performance, and accessibility still need their own passes. I keep a boring split in agency runbooks: probe for "is it up," scan for "is it shippable," portal for "here is the evidence."

Process that survives launch week

Pick the URL you actually mean to monitor. A heavy homepage behind a third-party widget can fail for reasons that are not "the API is dead." Some teams probe a lightweight health route and still schedule full scans on the marketing origin. Whatever you choose, write it down in the client portal.

Set the interval to match the promise you sold. Faster probes catch outages sooner. They also create more noise if the target is chatty. The product lets you choose the cadence; your process has to choose the responsibility.

When an incident opens, use the recorded failures and last error fields. When it closes, note duration and move on to a rescan if users reported broken behavior while the site was limping rather than dark.

# Pre-monitor sanity check before you enable client alerts
curl -sI "https://your-site.example/" | sed -n '1,15p'
# Confirm DNS/TLS with your usual tools, then verify the site in SlaySlop
# and set uptime interval in site settings

How I explain it to non-engineers

"Availability status means SlaySlop asked your public site if it would respond, saved the answer, and will open an incident if that answer is no three times in a row." Then I show the timeline. Then I show the separate scan report for quality. Two artifacts. Fewer awkward calls.

If you need that machinery on a property you manage, verify the site in SlaySlop, set the uptime interval, and keep incident history next to your handoff notes. The check is simple. The process around it is what keeps launch week boring in the good way.