Which Read the Docs alerting setup keeps build-failure signal but drops PR build noise?

We maintain a documentation project on Read the Docs (readthedocs.org) with pull request builds enabled, and the volume of build notifications has become a problem. Maintainers receive failure emails, and we also configured a project webhook that posts build events into a chat channel, but every PR and feature-branch build fires a delivery, so genuinely important failures on the default branch get buried.

My understanding is that the dashboard offers limited per-event control over email notifications, and that recipients are tied to project membership, while webhooks fire per build event with state and version fields in the payload. That suggests filtering has to happen downstream — in the chat integration or a small intermediary service — but I am unsure which combination is the intended, maintainable approach, and whether the community and commercial offerings differ here.

Assuming a current Read the Docs dashboard (settings may have changed over time):

• Can email failure notifications be scoped to specific versions or branches, or is the only lever the maintainer list itself?
• For webhook-based alerts, is filtering payloads by build state and version (e.g., failures on the default branch only) the documented way to cut noise, or is there a native event selection I am missing?
• Does disabling PR builds remove their webhook deliveries entirely, or do they still fire with a distinguishable build type?