Webhook 401s and reviews stopped firing

Reviews used to fire automatically on new pull requests, and now they don't. There is no error in the Azure DevOps UI, but the dashboard shows no recent review activity. The most likely cause is a webhook authentication failure: ADO is delivering events, but ADO Pilot is rejecting them with 401 Unauthorized because the webhook's credential no longer matches on our side. You can usually fix this yourself from the dashboard with Resync.

This page covers reviews that used to work and stopped. If reviews have never fired since you connected, see Reviews never started: service-hook permission error instead — a different, permission-related cause.

Symptom

What you observe

• New PRs are created or updated and ADO Pilot does not post a review or a status check.
• The Recent reviews list in your dashboard stops growing.
• Older PRs that were already reviewed look fine — the existing comments and status checks remain.
• Nothing in the Azure DevOps UI indicates anything is wrong. The PR looks normal.

What's happening behind the scenes

Each webhook subscription that ADO Pilot installed in your ADO org carries a credential that authenticates POST requests to our backend. When ADO sends a git.pullrequest.created or git.pullrequest.updated event, our gateway validates the credential before the event is processed. If validation fails, the event is rejected with 401 Unauthorized and the review is never queued. From your side, this looks like the system silently stopped working.

See Service hooks and webhooks for the full picture of what gets installed in your org.

Why it happens

Credential drift after an account change

Your subscription's credential is tied to your account state. If your plan was recently cancelled and reinstated, or support had to intervene on your account, the credential recorded on the Azure DevOps side can end up out of sync with the one ADO Pilot expects. The next event fails validation and gets a 401. Resync re-issues the subscriptions with the current, correct credential.

Manual subscription tampering

If someone in your org opens Project settings → Service hooks in Azure DevOps and edits the URL, the Resource details to send dropdown, or the headers on either of the ADO Pilot subscriptions, the next event fails authentication. Don't edit these subscriptions by hand.

How to fix it

You can resolve this yourself from the dashboard. All three controls are on the Integration settings page, in the Service Hooks card.

Check the live status

Click Check now. This reads the current state of each subscription directly from Azure DevOps. A healthy hook shows active; a broken one shows probation, disabled, or missing — any of those explains why reviews stopped.

Resync your hooks

Click Resync. This re-creates any missing or disabled subscriptions using your existing credential — it does not change your PAT. The 401s clear within a few minutes and reviews resume on the next PR push.

Confirm it worked

Click Test connection. This fires a synthetic event through the same path a real PR uses. Because Azure DevOps delivers this event asynchronously, the usual result is "Test event accepted — Azure DevOps is delivering it now" — the event was accepted for delivery, not yet confirmed arrived. A moment later, click Check now again (or watch the per-hook last-triggered time) to confirm the event actually reached ADO Pilot. A red result means the event was actively rejected, so the path is still broken — continue to the next section.

Still stuck?

If Resync reports failures or Test connection keeps failing, the cause is usually an expired or under-scoped PAT — see Rotating your PAT. If that doesn't help, open a support request with your Azure DevOps organization name, your ADO Pilot dashboard email, and the approximate time reviews stopped firing.

How to prevent it

There is nothing you need to do — webhook auth health is our responsibility. We monitor sustained 401 rates and alert ourselves before customer reviews are affected. The path you are reading this page on is the rare case where the alert fired late or the drift went unnoticed.

If you want belt-and-suspenders coverage, watch the Recent reviews list on your dashboard. A 24-hour gap during normal team-wide PR activity is your strongest signal that something like this is in play.