Subscribe to webhooks on the model repo. The Hugging Face Hub sends events for new commits and tags, repo moves and deletes, and config changes. Send those events to a small receiver that opens a review ticket, so a changed model never reaches production without a person looking.
What events exist
The Hub documents several webhook scopes. The ones that matter for dependency watching:
| Scope | What it covers |
|---|---|
| repo | Global events on a repo, with actions create, delete, update and move |
| repo.content | New commits or tags. It also fires on new pull requests, because those create a reference |
| repo.config | Settings changes such as visibility |
| discussion | Discussions and pull requests being created or updated |
Because repo.content also fires for pull requests, expect some noise. Filter on the reference in the payload so a community pull request does not look like a change to the branch you use.
Setting it up
- List the external models your code loads. If you have no list, start there. See how to find every model your code loads.
- Create a webhook for each watched repo, or one for a set of repos, pointing to an endpoint you control.
- Verify the webhook secret on every delivery before you act on it.
- Respond fast, then process from a queue so a slow ticket system does not cause retries.
- Map each event to an action, as in the table below.
| Event | Suggested action |
|---|---|
| New commit on the branch you track | Open a review ticket with the diff of files and hashes |
| New tag | Note it, no action unless you track tags |
| Move | Block promotion until the new owner is confirmed |
| Delete | Confirm your internal copy is intact |
| Visibility change | Check whether your build still resolves the repo |
What a good review looks like
An alert is only useful if the response is short and repeatable. Compare file hashes between the approved commit and the new one. Check whether any file format changed, for example a new pickle based file next to safetensors weights. Re-read the license and the model card. Then approve a new commit hash or stay on the old one.
If you pin by commit hash, an upstream change cannot affect your build until you choose to move. The alert exists so that choice is made with information, not by accident.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how monitoring turns a later change into a visible event.
Safeguard covers the dependency side of this with continuous scanning of the packages around the model and policy gates on changes. A free scan shows what your repository already depends on.
Quick check
Do webhooks replace pinning a commit hash?
No. Pinning stops a silent change from reaching your build. Webhooks tell you a change happened so you can review it.
Why do I get an event for a pull request I did not expect?
The Hub documents that repo.content events also trigger on new pull requests, since they create a reference.
Sources
Last reviewed: 19 October 2026.
