Automating Website Monitoring: What to Check Daily vs Weekly vs Monthly

Most websites aren't monitored at all. Or they're "monitored" by whoever happens to notice something odd, which usually means a customer emailing to say the checkout doesn't work, a week after it stopped working.

The opposite problem is just as real. Teams that set up alerts for everything soon learn to ignore them, and an ignored alert is no better than no alert.

The fix is a schedule that matches the frequency of each check to two questions:

1. How fast can this break?
2. How much does it cost while it's broken?

A site going completely down can happen any minute and costs everything while it lasts, so you check it constantly. A domain renewal can only fail once a year and gives you weeks of warning, so you check it monthly. Everything else sits somewhere in between.

Here's a practical schedule for a small business, blog, store or SaaS marketing site, with what to automate at each level and a few small scripts to get started.

Continuous (every few minutes): is it up?

What: Does the homepage, and your most important page (checkout, booking, sign-up, login), return a 200 quickly?

Why this often: An outage is total. Every minute down means every visitor is lost, and it can happen at any time from a host failure, a bad deploy, an expired certificate or a DNS mistake.

How to automate: An uptime monitoring service that requests a URL every few minutes from outside your network and alerts you (email, SMS, chat) when it fails. Many offer free tiers for a handful of URLs. Check that the monitor:

• Checks from outside your hosting provider (a monitor on the same server goes down with it)
• Looks for expected text on the page, not just a status code, because an error page can still return 200
• Requires a couple of consecutive failures before alerting, to avoid false alarms

Keep this list short: two to five URLs. This level is for "the site is down", not for every page.

Daily: is anything broken?

These are problems that don't take the site down but quietly cost visitors and sales. They can appear at any time (after an update, a content edit, a third-party change), and every day they go unnoticed costs you.

Broken links and missing images

Pages get edited, products get removed, external sites change, and links break. A daily crawl catches a broken "Buy now" button the day after someone deletes a product, not at the end of the quarter.

What to check:

• Internal links returning 4xx/5xx
• Missing images (404s on <img> sources)
• New redirect chains or loops
• Links to key conversion pages (cart, checkout, booking, pricing, contact) still resolving

I walked through doing this by hand for one platform in How to Find and Fix Broken Links on a Shopify Store. The daily version is the same checks, automated.

Certificate validity

Certificates are meant to renew automatically, but renewals do fail. Let's Encrypt certificates are valid for 90 days by default, and renewal is recommended every 60 days (Let's Encrypt FAQ). A daily check that warns when fewer than about 20 days remain gives you plenty of time to fix a stuck renewal:

#!/usr/bin/env bash
# cert-check.sh: warn if a certificate expires within N days
host="${1:?usage: cert-check.sh example.com [days]}"; days="${2:-20}"
cert=$(echo | openssl s_client -servername "$host" -connect "$host:443" 2>/dev/null)
end=$(openssl x509 -noout -enddate <<<"$cert" | cut -d= -f2)
if ! openssl x509 -noout -checkend $((days*86400)) <<<"$cert" >/dev/null; then
  echo "WARNING: $host certificate expires $end"; exit 1
fi
echo "OK: $host certificate valid until $end"

Backups completed

Not "are backups configured", but "did last night's backup finish?" Most backup tools can email on failure. Make sure that's turned on and goes to someone who reads it.

Key-page smoke test

A tiny script that requests your critical URLs and checks for the expected content:

#!/usr/bin/env bash
# smoke.sh: each line of urls.txt is "<url> <text that must appear>"
fail=0
while read -r url expect; do
  body=$(curl -sL --max-time 20 -w '\n%{http_code}' "$url")
  code=$(tail -n1 <<<"$body")
  if [[ "$code" != "200" ]] || ! grep -q "$expect" <<<"$body"; then
    echo "FAIL $code $url (missing: $expect)"; fail=1
  fi
done < urls.txt
exit $fail

One caution: don't automate form submissions or test purchases on a live site unless your platform provides a proper test mode. You'll fill your CRM with junk, trigger real emails or create real orders. Test forms by hand (weekly, below).

Running it on a schedule

Any scheduler works: cron on a server you control, your host's scheduled tasks, or a CI service. With GitHub Actions, for example:

name: daily-site-checks
on:
  schedule:
    - cron: "0 10 * * *"   # 10:00 UTC daily
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bash smoke.sh && bash cert-check.sh example.com

GitHub's documentation notes that scheduled workflows run on the default branch, can be delayed during periods of high load (particularly at the start of each hour), and in public repositories are automatically disabled after 60 days without repository activity (Events that trigger workflows). Pick an odd minute, and don't rely on this alone for time-critical alerts.

Weekly: the human checks

Some things need a person, or are slow-moving enough that weekly is fine.

• Test every contact path by hand: submit the contact form, try the booking flow, tap the phone link on mobile. Contact forms often fail silently after plugin updates or email configuration changes.
• Apply updates (CMS core, plugins, themes, dependencies), then re-run the daily checks and re-test forms.
• Glance at Google Search Console. It emails about new critical issues, but a weekly look at Indexing → Pages for rising 404 or server-error counts catches slower trends.
• Read the week's daily reports and fix anything still open.

Monthly: performance, content and access

• Core Web Vitals. Search Console's Core Web Vitals report "shows how your pages perform, based on real world usage data" (Core Web Vitals report). Because it reflects real visitors over time, it moves slowly, so monthly is the right cadence. Google's targets are LCP within 2.5 s, INP under 200 ms and CLS under 0.1 (Core Web Vitals). Use PageSpeed Insights to diagnose any template that's slipping.
• Content accuracy: prices, hours, staff, service areas, promotions that should have ended.
• Outbound links on your most-visited pages, opened by hand, to check they still say what you linked them for. A status-code checker can't tell when a page changed content.
• Access review: remove accounts for people who no longer need them (CMS, hosting, registrar, analytics).
• Business listings: check that the website URL on your Google Business Profile and other directories still points at a working page.

Yearly: renewals and recovery

• Domain renewal. Registrars of generic top-level domains must send at least two expiry reminders, about one month and about one week before expiry, under ICANN's Expired Registration Recovery Policy. That only helps if the contact email is current. Turn on auto-renew and confirm the payment card.
• Restore test: restore a backup somewhere safe and confirm the site works.
• Documentation: who owns the domain, hosting, DNS, email and each account, and when each renews.
• Accessibility and SEO review of key templates.

For a non-technical version of this list, see The Website Maintenance Checklist for Small Business Websites.

Alerts versus reports

One last design decision makes the difference between monitoring people use and monitoring they mute:

• Alerts (immediate, interruptive) are only for things that need action now: site down, checkout down, certificate expiring within days.
• Reports (daily or weekly digests) are for everything else: broken links, missing images, redirect chains, slow templates. Nobody needs a 2 a.m. page about a broken link in a blog post from 2021, but they do need to see it in tomorrow's report.

If an alert fires and the right response is "I'll look at it later", it should have been a report.

Disclosure: I build Uchik, which handles the daily report layer. Uchik crawls your site once a day with read-only requests (it never submits forms or places orders) and emails a report of broken links, missing images, redirect chains, mixed content and basic SEO gaps, each tied to the exact page and HTML element. How it works explains the crawl, the features page lists the checks, and the sample report shows what arrives in your inbox. It isn't an uptime monitor and it doesn't measure Core Web Vitals, so pair it with the continuous and monthly checks above. Links added only by JavaScript may be missed. You can sign up for free.

The schedule on one page

Cadence	Check	Automate?
Every few minutes	Homepage + critical page up, expected text present	Yes: uptime monitor
Daily	Broken links, missing images, redirects	Yes: crawler
Daily	Certificate expiry > ~20 days	Yes: script or monitor
Daily	Backup succeeded	Yes: backup tool alerts
Daily	Critical URLs return expected content	Yes: smoke script
Weekly	Forms, booking, phone links	No: test by hand
Weekly	Updates applied, then re-tested	Partly
Weekly	Search Console indexing trends	Email alerts + quick look
Monthly	Core Web Vitals (field data)	Report; review by hand
Monthly	Content accuracy, outbound links, access, listings	No
Yearly	Domain renewal, restore test, documentation	Auto-renew + calendar

Start with the first two rows this week. Together they cover most of what quietly costs small sites visitors and sales.