Fixing Availability Status without guessing

When a site "looks down," people guess. They bounce the app server. They purge the CDN. They rewrite a health check that was never the problem. Availability status is fixable without that theater if you treat it like metadata you can verify: which URL was probed, which status codes count as up, what the recorded series shows, and which infrastructure signals sit next to the failure.

SlaySlop defines Availability status as the check that "checks whether the public site responds and records its state." The product about line adds: it checks if a server is online and responding to requests. Your fix plan should restore a true response on the URL that matters, then prove the recorded state followed. Anything else is decoration.

I edit thin pages for a living. Thin monitoring configs have the same smell: a vague green/red without the fields a later reader needs. Fix the fields first.

Step 1: lock the probe URL to the real dependency

Monitoring on SlaySlop names the probe URL as the URL each availability check GETs. If the homepage needs auth, change the path in monitor config. Before you change application code, write down the URL that failed and the URL users actually need.

PROBE="https://app.example.com/health"
curl -sI "$PROBE" | sed -n '1,15p'

Expected outcome: you can point at a single status line and say whether that line matches the contract. If /health is a 200 shell that never touches the database your checkout uses, pick a deeper dependency check or accept that you are only measuring "process up," not "checkout up." Say which one you chose. Guessing here wastes every later step.

Step 2: make accepted status ranges explicit

SlaySlop lets you define accepted status code ranges: inclusive ranges counted as up. A common silent failure is a health endpoint that returned 204 for years while someone assumed only 200 counted, or the reverse. Another is a login wall returning 401 on the probe path after a routing change.

Write the contract in the config, not in Slack lore:

accepted_status_ranges:
  - from: 200
    to: 299
# If your LB health check must be exactly 200:
# - from: 200
#   to: 200

After you change ranges, do not declare victory from one manual curl. Wait for probes to run on the schedule you configured. Monitoring says probes run around the clock at the interval you choose.

Step 3: use incident hysteresis instead of flapping your hands

Product copy for monitoring is specific: three failed checks open an incident, and three successful checks close it. That is your verification gate. A single recovered curl in your terminal is a hopeful anecdote. Three successful probes in the recorded series is a closed incident with timing you can keep.

When you are mid-fix, watch for flap: fail, ok, fail, ok. That pattern usually means you are probing across an unstable edge (bad deploy slot, drained instance, DNS half-updated) rather than a clean outage. Fix the instability; do not widen accepted ranges to hide it unless you intentionally want a softer definition of "up."

Step 4: repair the layer the evidence names

Domain insights on SlaySlop exists to collect public DNS, TLS, hosting, and mail signals, and it states that infrastructure signals support availability diagnosis. Before you rewrite application code, check whether the probe still resolves, whether TLS handshakes, and whether redirects send the GET somewhere unexpected.

# Permissioned hosts only
dig +short app.example.com A
echo | openssl s_client -servername app.example.com -connect app.example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject
curl -sI "https://app.example.com/health" | sed -n '1,20p'

Map results to actions:

• DNS missing or wrong: fix nameservers or records, then wait for the TTL you actually configured.
• Certificate expired or name mismatch: renew or correct the cert; availability will stay down for HTTPS clients even if port 80 answers.
• Unexpected redirect chain: straighten the chain so the probe URL lands on the service you meant.
• Origin 5xx with good DNS and TLS: now you have earned an application or gateway investigation.

Step 5: confirm recovery the way crawlers and clients will

Editors and answer engines do not care about your internal dashboards. They care whether the public URL responds. After infrastructure or app fixes land:

1. Confirm the probe URL still matches the public dependency.
2. Confirm the latest probes fall inside accepted ranges.
3. Confirm the incident closed under the three-success rule.
4. Spot-check a second path users hit (homepage, login, API) even if it is outside the probe, so you did not repair only the health endpoint.

Scheduled rescans on SlaySlop are described as catching problems that come back after a fix. Availability is the same idea on a shorter loop. Leave monitoring active. Product copy notes probes can be paused and resume when monitoring is active; do not "fix" an outage by muting the only recorder you have.

What not to invent while fixing

Do not invent scan durations, prices, or unpublished check behavior. Cite Pricing when money matters. Do not treat availability recovery as a security clearance; SlaySlop remains a read-only public scan, and permission still applies for URLs you do not own or manage. Deep offensive testing is a different job.

Done looks like this

The probe URL is written down. Accepted status ranges match the service contract. DNS and TLS evidence match the story. The incident opened on three failures and closed on three successes. A second public path still answers. That is a fix without guessing. Soft pass: if you want the recorder and the surrounding public checks in one place, run the site through SlaySlop on a URL you are allowed to test and keep the evidence next to the status change.