Uptime Checks

Outcome

You will know what uptime checks are good for, how to set one up, and what to do when one fails so the alert turns into a useful action rather than noise.

What They Tell You

Uptime checks answer a simple but important question: is the site reachable from the outside right now? They run from an external location on a regular cadence and record whether the site returned a healthy response inside an expected window.

That single signal is valuable because it is independent of anything happening inside the application. If the check fails, something between a real visitor and your site is not working, and that is worth knowing fast.

What They Do Not Tell You

An uptime check alone does not explain why the site failed or whether the issue is content, hosting, DNS, caching, or application behavior. Treat it as the start of an investigation, not the whole answer.

Set Up a Check

1. Open the site in TMXIO and find the monitoring or uptime area.

2. Add a new check and point it at the URL you want monitored. For most sites this is the production home page; some teams also add a check for a critical interior page such as a login or checkout flow.

3. Pick the cadence. A one-minute interval is the most responsive, but a five-minute interval is often enough for routine monitoring and produces less alert noise.

4. Choose who should be notified when the check transitions to a failing state, and through which channel.

5. Save the check and wait one full cycle to confirm the first healthy result is recorded.

Severity and State Reference

State	What it means	Typical action
Healthy OK	The last check returned successfully inside the expected window	None; routine monitoring
Degraded Warn	Recent checks are slow or intermittent but the site still responds	Investigate during business hours; watch for trend
Down Critical	The check has failed and the site is not responding correctly	Page the on-call owner and begin triage
Paused Paused	The check is temporarily disabled, usually for planned maintenance	Re-enable after the maintenance window

When a Check Fails

1. Open the failed check in TMXIO and confirm the failure is consistent, not a single timed-out attempt.

2. Try the URL yourself from a normal browser. If it loads for you, the issue may be regional or transient.

3. Identify whether the site is hosted by TMXIO or external, then move into the matching troubleshooting flow. Hosted sites have a different recovery path than self-hosted sites connected by plugin.

4. Once the site recovers, confirm the check returns to Healthy and note the time of recovery for the incident record.

Alert cadence

Tune the notification cadence so on-call teammates are not paged for every brief blip. A single failed probe is rarely worth a wake-up; two or three consecutive failures usually is. Most teams settle on a short consecutive-failure threshold rather than alerting on the very first miss.

What Success Looks Like

• Every production site has at least one uptime check pointed at a public-facing URL
• Alerts route to a real person or team who can act on them
• Recovery is recorded so trends across weeks are visible, not just the current state