# Event website uptime monitoring setup sheet

One row per monitored public surface. Confirm vendor-specific check behavior before configuring a production monitor. Do not put tokens, real purchases or attendee data in probes.

| Event edition / URL | Surface and owner | HTTP status / content signal | Redirect policy | Probe locations | Interval / timeout / failed checks | Primary receiver / backup / time zone | Escalation and independent status channel | Safe test-alert result | Next review |
|---|---|---|---|---|---|---|---|---|---|
| Example: public event details | Event site / web owner | Expected event marker | Document | Audience regions | Choose for risk and cost | Named people | Document | Pending | Date |
| Registration entry | Ticketing owner | Provider-specific | Document | Relevant locations | Document | Named people | Document | Pending | Date |
| Official checkout link | Hosted provider / organizer liaison | Reachability only unless approved deeper check | Document | Relevant locations | Document | Named people | Document | Pending | Date |

## First-response card

- Open the failing URL from a second network or location when possible.
- Identify whether the public page, registration, checkout provider or DNS/domain is affected.
- Contact the named owner and backup using a channel that works if the event domain is down.
- Record start time with zone, affected audience, observed error and next update time.
- Use an approved test-alert feature or safe endpoint to prove delivery; never break live ticket sales.
- After resolution, review alert noise, response time and monitored URLs.

A successful HTTP probe cannot establish that a payment or registration completed. Some HTTPS health checks also do not validate certificate expiry; use a separate certificate monitor when needed.