Skip to main content
The web-unified-docs repository uses a focused broken link monitoring system that provides visibility without blocking development. The system separates PR-time feedback (informational) from production monitoring (critical alerts).

How the system works

PR previews

Shows all broken links found in changed files as a PR comment. PRs never fail due to broken links. Development continues unblocked.

Production monitoring

Weekly full content scan every Monday. Broken links are logged to Datadog and tracked in a single auto-updated GitHub issue.

PR previews (informational only)

When you open or update a pull request, the link checker scans the content and posts a comment listing any broken links it finds.
  • PRs never fail due to broken links.
  • All broken links are shown in PR comments for awareness.
  • No Datadog alerts are triggered for PR previews.
  • Development continues unblocked.
The link checker scans all content, not just the files you changed. It is normal to see broken links in your PR comment that are unrelated to your changes. Focus on fixing broken links in files you directly modified.

Production monitoring (critical alerts)

The production monitoring system runs a full content scan every Monday and targets issues that directly affect end users.
  • Weekly scan — every Monday, all published content is checked.
  • GitHub issue — a single “Link Checker Report” issue is auto-updated with the latest results.
  • Datadog logging — production broken links are logged and trigger alerts.
  • Auto-close — the previous issue is closed when a new one is generated.
To find all currently known broken links in production:
  1. Go to the repository’s Issues tab.
  2. Filter by label: link-checker-report.
  3. Open the most recent issue — it contains all current production broken links.
Or use the GitHub Issues search query:
label:link-checker-report is:open
To view all historical reports:
label:link-checker-report
A dedicated workflow is available for teams migrating products to the Unified Docs Repository. It lets you check links for a specific product before migrating. Workflow file: .github/workflows/udr-product-link-check.yml
1

Navigate to the workflow

2

Run the workflow

Click Run workflow.
3

Select your product

Choose your product from the dropdown (e.g., terraform, vault, consul).
4

Optionally specify custom paths

Enter custom paths to check if you want to limit the scan to a specific subdirectory.
5

Review the results

When the workflow completes, review the results in the generated GitHub issue.
You can run the broken link checker locally to preview results before opening a PR. To check all content:
$ npm run broken-link
To check a specific product directory:
$ npm run broken-link terraform-plugin-framework
Replace terraform-plugin-framework with the directory name of the product content you want to check.

Datadog monitoring

Production broken links are tagged in Datadog for alerting and tracking. Only production events generate Datadog entries — PR previews produce no Datadog noise.

Tags

TagValue
environmentproduction
serviceweb-unified-docs
alert_typebroken_links_production

Query

logs("@dd.tags:environment:production AND @dd.tags:alert_type:broken_links_production")

Best practices

  1. Review PR comments — check which links are broken in your changes.
  2. Fix critical internal links — but don’t let external issues block your PR.
  3. Monitor the weekly GitHub issue — stay aware of overall link health.
  4. Focus on content quality — write accurate links and double-check paths before merging.

Troubleshooting

For temporary external outages:
  • Check if the site recovers before merging.
  • Consider whether the link is essential to your content.
  • Document known unreliable sources in your team’s notes.
The system is intentionally non-blocking at PR time for these reasons:
  1. External links can break at any time, beyond any contributor’s control.
  2. Development velocity shouldn’t be blocked by external site issues.
  3. PR previews are for testing, not final production validation.
  4. Full visibility is maintained through PR comments without forcing a failed status check.

Build docs developers (and LLMs) love