Run Bug Reports in Your CI Pipeline:
A Complete Setup

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

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: ./reports

Every 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

1. Create the workflow file. Save it as .github/workflows/post-deploy.yml in your repository.
2. Point the URLs at your own site. Replace example.com everywhere. For staging environments, duplicate the job with your staging URL.
3. For bugbottle: point path at the directory where report files land. If you don't collect reports yet, remove that step — the other two stand alone.
4. 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.