Why a cron job beats a monitoring dashboard
Most uptime monitors want a monthly subscription, an account, and another inbox of alert emails. If you already ship your site through GitHub, you have a scheduler, a runner and a notification channel (failed workflow runs email the repo owner by default) sitting there unused.
This setup runs on public repositories for free, needs no secrets, and every check is a plain YAML step you can read in seconds. It catches the failures that actually happen to small sites: expired certificates, a redesign that dropped the cookie banner, a redirect rule that broke after a deploy.
The complete workflow
Save as .github/workflows/site-health.yml:
name: Site health
on:
schedule:
- cron: '0 6 * * *' # daily at 06:00 UTC
workflow_dispatch: # also runnable manually from the Actions tab
jobs:
health:
runs-on: ubuntu-latest
steps:
- name: Uptime + SSL certificate expiry
uses: mahope/deskuptime@v1
with:
url: https://your-site.com
- name: EU compliance intact (privacy policy, headers, meta)
uses: mahope/compliance-site-check@v2
with:
url: https://your-site.comReplace your-site.com with your domain. Both actions pin floating major tags, so bug fixes arrive automatically without breaking changes.
What each action checks
deskuptime@v1
Fetches the URL and fails if the page does not respond correctly, warns when the SSL certificate is close to expiry, and can detect unwanted content changes. Zero dependencies — no npm install, no config files.
compliance-site-check@v2
Nine GDPR/EAA-oriented checks against the live page: privacy-policy reachability, cookie-consent signals, security headers (CSP, HSTS, XFO), SEO meta tags and language declaration. A silent regression turns red before your users or a regulator notice.
Two more steps for teams that publish content
The same workflow can carry two optional jobs:
- Content integrity:
mahope/clean-copy-cli@v1converts a live page to Markdown inside the workflow and exposes it as step outputs — useful to snapshot documentation or diff a changelog between runs. - Bug-report quality: if you collect in-app reports with bugbottle,
mahope/bugbottle-action@v1validates collected reports in CI so low-quality submissions never reach your issue tracker.
Scheduling tips
- Cron times on GitHub Actions are in UTC.
'0 6 * * *'is 08:00 in Copenhagen (CEST). - Scheduled workflows only run on the default branch, and can be delayed a few minutes during peak hours — fine for daily monitoring, not for sub-minute alerting.
- GitHub disables schedules on repos with no activity for 60 days; any commit re-enables them. Pinning a comment or bumping a date keeps an idle repo alive.
What it replaces
Uptime-monitoring SaaS typically starts around $10–15/month per site ($120–180/year per site), and a manual compliance review starts in the thousands. This stack costs nothing on public repos and fits in one file you own. For sub-minute paging during incidents, dedicated monitoring still has a place — but for "did my site silently break?", a daily cron job catches it within 24 hours at zero cost.
Related guides
Try the compliance half right now
No repo needed to see what the scanner finds on your live site — free, no signup, results in about a minute.
Scan your site free →The cron job is free. The incident channel is not.
Everything in this guide is free, and it stays free: the daily workflow, the two actions it calls, and the two optional jobs. The DeskUptime command line tool behind deskuptime@v1 is the same tool you can install today — one-off checks, SSL and content checks and JSON output, on as many sites as you like. No account, no key, no trial. If your only question is "did my site silently break?", the cron job above already answers it.
What it cannot answer is the part the article hands to you twice in its own text. The alert arrives as a failed workflow email — the same "another inbox" the opening paragraph argues against — and the schedule notes concede the timing: "fine for daily monitoring, not for sub-minute alerting", once a day, on the default branch only. DeskUptime Pro adds exactly five things, and all five are named limits in the text above.
| What you get | Free | DeskUptime Pro — $19 once |
|---|---|---|
| This guide and the two GitHub Actions it installs | this page, in full | included |
| Checking a site from your terminal or a workflow | one-off checks | included |
| Certificate expiry and silent content changes | SSL and content checks | the same checks |
| Machine-readable step output | JSON output | included |
| Where you look when something is wrong | the Actions run log, once a day | desktop app |
| How the failure reaches you during an incident | the GitHub Actions failure email | webhook alerts — Slack, Teams, PagerDuty |
| How often a site is checked | once a day, on the default branch | every 30 second |
| How many sites one licence covers | three URLs | unlimited sites |
| What you attach when the client asks | — | client-ready report |
One-time price, three machines — the licence activates on the machine you run the CLI on, not per site. If a daily email is enough for a one-person site, the free cron job is the whole answer and you never need to pay for anything.