Read the Docs and GitHub Webhook Integration: Build Failure Notification Granularity
0 reputation · 27 Aug 2025, 02:10 UTC
0 reputation · 27 Aug 2025, 02:10 UTC
Read the Docs integrates with GitHub via webhooks to automate documentation builds upon commits to tracked branches. While the platform allows maintainers to enable build failure notifications via email, the current configuration options apply broadly to the project's build status.
In environments with multiple tracked versions—such as a stable production branch and several active development branches—a high volume of commits to unstable branches can generate significant notification noise. This makes it difficult to distinguish between a critical failure on the stable version and a routine build error on a feature branch.
Is it possible to configure notification alerts to trigger only for specific tracked branches? If global settings are the only option, what is the recommended approach to isolate critical stable-build alerts from development noise?
34775 reputation · 27 Aug 2025, 11:55 UTC
No, it is not currently possible to configure Read the Docs (RTD) to trigger build failure email notifications for specific tracked branches only. The notification settings are global to the project; if build failure notifications are enabled, an alert is sent regardless of whether the failure occurred on the stable version or a development branch.
Because RTD treats every tracked version as a first-class build target, any commit to a branch configured as a "version" triggers a full build process. When global notifications are active, the platform does not distinguish between a critical production regression and a transient error in a feature branch, leading to the "noise" experienced in multi-branch environments.
To isolate critical stable-build alerts from development noise, you must shift the notification logic away from the RTD global settings and toward an external integration. The recommended workflow is as follows:
version field matches your stable/production branch.To verify the data available for filtering, you can use a tool like Webhook.site to capture a live payload from Read the Docs. Ensure you are checking for the following key in the JSON response:
{ "version": "stable", "status": "failure", ... }
Diagnostic Detail Needed: Are you using the Read the Docs hosted platform (readthedocs.org) or a self-hosted instance? Self-hosted instances may allow for deeper configuration of the conf.py or server-side hooks that are unavailable on the hosted version.
Use comments to ask for clarification. Post a solution as an answer.
5,940 reputation · 27 Aug 2025, 06:09 UTC
One clarification on the webhook listener approach: the GitHub webhook that triggers Read the Docs builds is an incoming trigger, not an outgoing notification channel. Filtering its payload in a custom service works, but it requires maintaining middleware.
A lower-maintenance alternative is to use the commit statuses Read the Docs posts back to GitHub. You can require the documentation check only on protected branches via branch protection or repository rules. This surfaces stable-branch failures directly in GitHub's pull request and commit views without a separate notifier. Development branches can still build, but their failures will not block or alert through the protected-branch rules.
Verify in your GitHub repository settings which statuses the integration posts and confirm that protection rules apply the docs check only to your production branch pattern.