Why put reporting in CI?
Your CI pipeline runs on every push whether anyone is watching or not. That makes it the cheapest place to answer questions that otherwise need a person: did a new deploy break accessibility? Is the site even up? Are bug reports coming in valid? A step that fails loudly in CI costs seconds; the same problem discovered by a user costs trust.
All three actions below are plain YAML steps with no account signup, no API key, and no SaaS subscription. Each one is pinned to a floating major tag (@v1 / @v2) so you get fixes automatically without surprise breaking changes.
The three actions
1. Validate bug reports: bugbottle-action@v1
If you collect bug reports as JSON files (from a feedback widget, a form export, or a script), this action validates them against the schema inside your workflow. A malformed report fails the build instead of silently rotting in a folder. It exits non-zero on invalid input, so it works as a gate before release.
2. Keep the site up: deskuptime@v1
A dependency-free uptime check that runs wherever your CI runs. Point it at any URL and it fails the step if the page does not respond as expected. Useful as a post-deploy smoke test — especially for static sites where "the deploy succeeded" and "the site works" are different questions.
3. Catch compliance regressions: compliance-site-check@v2
Runs a GDPR/EAA-oriented compliance scan against a URL and surfaces failures in the job log. Add it after each deploy so a removed privacy policy link or broken consent mechanism shows up in the same place your tests do.
A complete example workflow
This workflow runs after deployment: it checks the site is up, scans compliance, and validates any collected bug reports:
name: Post-deploy checks
on:
schedule:
- cron: '0 6 * * *' # daily at 06:00 UTC
workflow_dispatch:
jobs:
checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Site is up
uses: mahope/deskuptime@v1
with:
url: https://example.com
- name: Compliance scan
uses: mahope/compliance-site-check@v2
with:
url: https://example.com
- name: Validate bug reports
uses: mahope/bugbottle-action@v1
with:
path: ./reportsEvery step either passes or fails visibly. No dashboard to log into, no email digest to ignore — red is red, in the same place your team already looks.
Setup, step by step
- Create the workflow file. Save it as
.github/workflows/post-deploy.ymlin your repository. - Point the URLs at your own site. Replace
example.comeverywhere. For staging environments, duplicate the job with your staging URL. - For bugbottle: point
pathat the directory where report files land. If you don't collect reports yet, remove that step — the other two stand alone. - Commit and run once manually via workflow_dispatch to confirm everything is green before trusting the schedule.
No secrets are required for any of the three actions, since none of them call external services. They read your inputs and act on them locally in the runner.
What this replaces
A typical uptime-monitoring SaaS starts around $10–15/month per site. Compliance audits run $2,000–10,000 per engagement. Neither catches regressions between check-ins. A daily CI job does both continuously, for free, on infrastructure (GitHub-hosted runners) you already pay for — free for public repositories, and included minutes for private ones.
Related guides
Try it on your site first
Before wiring CI, see what the compliance scanner finds on your live site — free, no signup, results in about a minute.
Scan your site free →The CI job is free. Watching between builds is not.
Everything in this guide is free, and it stays free: the three actions, the workflow file, and the runner minutes. 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 the last deploy break the site?", the second action above already answers it.
What it cannot answer is the part the article hands to you in its own text. The schedule is cron: '0 6 * * *' — daily at 06:00 UTC — so everything the guide asks you to build is blind for the other 23 hours and 59 minutes of the day. The opening paragraph makes the same point about timing: a problem found by a user costs trust, and a user only finds it when they happen to look. The steps are also read in a job log nobody opens between builds, which is the "inbox" this whole guide argues against. 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 three 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 job log, when you happen to open it | desktop app |
| How the failure reaches you | a red row in the Actions log | 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 job log is enough for a one-person site, the three actions above are the whole answer and you never need to pay for anything.