Nothing happened — what to check

You opened a pull request and got no comment. That is either working perfectly or completely broken, and by design those look identical.

Work down this list. It is ordered by how often each thing is actually the problem, not by how the system is layered.

1. Did the webhook get delivered?

GitHub → your App → Advanced → Recent Deliveries.

This one question eliminates most of the tree, because it tells you whether the problem is on GitHub’s side of the line or ours.

• No delivery listed at all → GitHub never called us. The App is not installed on this repository, or it is not subscribed to the Pull request event. Check which repositories the installation covers: installing on the wrong repo, or on your personal account rather than the organisation, is the single most common cause.
• A delivery with a red response → we were called and something went wrong. Read on; the status code tells you which.
• A delivery with 200 → we accepted it. Skip to step 4.

2. A 503 from /webhook

503 means the App is not configured on the server. The instance received your delivery and had no App ID, private key or webhook secret to verify it with.

Set GARBOARD_GITHUB_APP_ID, GARBOARD_GITHUB_PRIVATE_KEY_FILE and GARBOARD_WEBHOOK_SECRET. On a self-hosted install, see self-hosting.

3. A 401 from /webhook

The signature did not verify. Your GARBOARD_WEBHOOK_SECRET and the secret in the App’s settings are different strings. Re-enter both; do not copy from a terminal that may have wrapped it.

4. Is the server actually up?

curl -sS https://your-garboard/healthz

Expect ok. If this fails, nothing else in this list matters.

Note that /healthz says ok on any running version, and it stays ok when the database credential has expired — the process is alive and existing connections work while new ones fail. If sign-in is also failing, suspect the database URL before anything else.

5. Is there an RCD for this repository?

A review loads the conventions derived by an earlier scan. No scan, no conventions — and a repository whose conventions have never been derived produces far fewer findings than you expect, sometimes none.

Open the repository in the UI. If it has never been scanned, scan it.

6. What does the check run say?

Garboard posts a check run on the commit. Its state distinguishes cases the comment cannot:

• No check run at all → we never processed the delivery. Go back to step 1.
• Success, no comment → we reviewed it and had nothing to say. This is the correct-silence case, and at this point you have proven it.
• Neutral with an attribution note → someone used break-glass on this review.

7. The server log

Grep for the repository or the pull request number. The lines worth looking for:

• store: episodic memory disabled (pgvector unavailable) — not your problem here, but it means the install is degraded in another way and is worth fixing.
• Any line naming your repository around the delivery time. Its absence, given a 200 at step 1, is the interesting case: it means the event was accepted and then filtered — usually because the pull request changed no infrastructure files at all.

8. Did the pull request change any infrastructure?

Garboard reviews changed infrastructure files. A pull request that touches only README.md, only application code, or only files outside the paths it watches, is correctly ignored.

This is worth checking last and believing first: it is the most common cause of “nothing happened” once the install is genuinely fine.

Still nothing

If you have a 200 delivery, a healthy server, an RCD, and a pull request that genuinely changes Terraform — that is a bug and we want it. hello@winchlabs.io, with the delivery id from step 1.