Uptime monitoring setup in brief
To monitor a website's uptime, list the few URLs whose failure would hurt users and add them to an always-on monitoring service that checks from several locations. Set a check interval, a failure threshold and alert channels. Then plan maintenance windows and re-check your key URLs after every release.
Choose the URLs that matter
Monitor the pages and endpoints whose failure costs users or revenue. A short list keeps alerts meaningful, and finding broken pages across the whole site is a job for a crawl.
For pages that can return 200 while showing an error, add a keyword check for text that appears only when the page works. Testing a full sign-in or purchase takes a scripted multi-step check, which some services offer as a separate check type.
- The homepage and your top landing pages
- The login page, and the signup or checkout page
- A health endpoint for your app or API that returns 200 only when its database and other dependencies respond
- Public API endpoints that customers call
- DNS and the TLS certificate for each domain you serve
Use a dedicated always-on monitoring service
Scheduled checks need something running around the clock outside your own infrastructure. A monitor on the same server, network or cloud region as your site can fail along with it and send no alert.
Choose a service that checks from several regions and supports the check types you need: HTTP status, keyword, DNS and certificate expiry. It should keep a history of results and alert through channels your team already watches.
A self-hosted monitor works too, as long as it runs on separate infrastructure.
Set intervals, thresholds and alert channels
These settings decide how quickly you hear about an outage and how often you're woken for nothing.
- Check revenue-critical pages and APIs every minute and other pages every 5 minutes. Certificate and domain expiry can be checked daily.
- Fail a check that gets no response within 10 to 30 seconds, and flag responses slower than your normal range as degraded.
- Name the status code you expect, usually 200, and decide whether a redirect counts as up. A homepage that suddenly redirects to an error page shouldn't pass.
- Alert only after failures from at least two locations, or after two consecutive failed checks.
- Page the on-call person for confirmed outages of key URLs, send warnings to chat or email, and make sure at least two people receive critical alerts.
- Escalate when nobody acknowledges an alert within a set time, and send a notice when the check passes again.
- Test the alert path by pointing a monitor at a URL that returns 404 and confirming the alert reaches the right people.
Plan maintenance windows
Planned work fails checks without being an incident. Schedule a maintenance window in your monitoring service that pauses alerts only for the affected monitors and only for the planned time. Set it to end on its own, so monitoring stays on afterward.
Announce the window on your status page in advance. While the site is down, return 503 Service Unavailable with a Retry-After header instead of a 200 error page. Monitors and search engine crawlers then both see a temporary outage.
Re-check key URLs after every release
A release can cause an outage through a changed route, a missing environment variable or a broken redirect. Scheduled monitors cover only a handful of URLs, so a release can break a page they never request.
After each deploy, check a wider list of important URLs for status codes, redirects and response times, and compare the results with the run before the release. You can automate this as a smoke test in your deployment pipeline.
MemonaIQ doesn't run scheduled uptime checks, but for this step you can paste your list into URL Intelligence Platform's checker. It requires a free account, and checks come out of a daily allowance of 250 on the free plan. Past checks stay in your browser's history, so you can compare two runs.