docs(metrics): rename Monitors feature to Alerts

[marksalpeter]

Summary

The docs call the threshold-alerting feature "Monitors" (borrowed from Datadog terminology), which collides with the broader "Monitoring" stage of the AI engineering loop and reads less intuitively than "Alert" (as flagged by @clemo in the #product-langfuse thread).

To achieve this we:

• Renamed the feature to Alerts across the docs site, including the page URL, sidebar entry, pricing tables, and the self-hosting compatibility matrix
• Resolved the two terminology collisions the rename creates: since alert is now the configured entity, the events it emits are consistently called notifications; and where the renamed feature appears alongside the pre-existing Spend Alerts billing feature, it is qualified as cost-metric alerts so neither reads as a subtype of the other
• Added a permanent redirect from the old /docs/metrics/features/monitors URL
• Updated every cross-reference in the FAQ, engineering resources, blog posts, integration pages, and handbook

Note: app routes (cloud.langfuse.com/project/~/monitors), the webhook payload schema (type: "monitor-alert", monitorId), and the feat-monitors discussions label keep the legacy naming, per the ticket's DoD that internal seams stay put. The docs page now carries a callout stating the payload naming is unchanged so existing integrations keep working. Changelog entries keep their dated prose as a historical record — only their card labels and canonical links were updated.

Fixes LFE-14881

Verification

• pnpm run format:check — all matched files use Prettier code style
• node scripts/check-h1-headings.js — no multiple-H1 violations
• node scripts/copy_md_sources.js — Markdown source generated at public/md-src/docs/metrics/features/alerts.md
• Dev server: /docs/metrics/features/alerts returns 200 with title "Alerts"; /docs/metrics/features/monitors returns 308 to the new URL
• Dev server: /pricing and /self-hosting/upgrade/versioning return 200
• Swept every file touched by the rename for co-occurrences with "spend alert"; only the cost management guide needed disambiguating
• pnpm build + pnpm link-check (left to CI)

Test plan

• Open the Alerts docs page, confirm the sidebar reads "Alerts" under Metrics → Features and that in-page anchor links (#alert-setup, #alert-states, #automations) all resolve
• Visit the old /docs/metrics/features/monitors URL, confirm it redirects to /docs/metrics/features/alerts
• On /pricing, confirm the row reads "Alerts" with limits of 2 / 20 / 50 / 100 alerts, and that the rendered table matches md-override/pricing.md
• On /self-hosting/upgrade/versioning, click the "Alerts" row and confirm the expandable detail panel still opens (the CompatDetail name must match the row label)
• Read the "Control spend before the invoice arrives" section of the LLM cost management guide and confirm cost-metric alerts and spend alerts read as two distinct features
• Confirm the severity table still documents ALERT and the Alert threshold field, matching the strings the app emits

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation and redirect-only changes with no application logic; risk is limited to broken links or inconsistent terminology, which the PR appears to address systematically.

Overview
Renames the threshold-metric feature from Monitors to Alerts across the docs site, pricing, and cross-links, with the primary page at /docs/metrics/features/alerts and a permanent redirect from /docs/metrics/features/monitors.

Copy is updated so an alert is the configured rule and notifications describe what fires on severity changes (including automation setup and renotify wording). Pricing and self-host tables now show alert limits (2 / 20 / 50 / 100); the alerts doc adds a callout that webhook payload fields (monitor-alert, monitorId) stay legacy for existing integrations while app URLs under ~/monitors are unchanged in prose.

^{Reviewed by Cursor Bugbot for commit 8e5392b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-docs	Ready	Preview	Aug 10, 2026 3:22pm

[github-actions]

@claude review

[claude]

LGTM — mechanical, well-scoped rename with one wording nit flagged inline that doesn't affect correctness.

Extended reasoning...

Overview

This PR renames the "Monitors" feature to "Alerts" across the docs site: the feature page (renamed file + URL), sidebar meta.json, pricing tables (React component and both md-override sources), the self-hosting compatibility matrix, changelog card labels/canonical links, and every cross-reference in blog posts, FAQ, engineering resources, the Slack integration page, and the handbook. A permanent redirect from the old /docs/metrics/features/monitors URL is added in lib/redirects.js.

Security risks

None. This is a pure content/copy and redirect change with no application logic, auth, or data-handling code touched.

Level of scrutiny

Low-to-medium. The change is large in file count (size:L) but each file's diff is a mechanical, low-ambiguity string/link substitution following one consistent naming decision (monitor → alert, monitor-firing → notification). The PR correctly preserves intentionally-unchanged internal seams (app routes, webhook payload schema, feat-monitors label) and documents that decision with an in-page callout, which is the trickiest part of this kind of rename to get right.

Other factors

• md-override/pricing.md and md-override/pricing-self-host.md were updated in the same change as the pricing table component, keeping the override/rendered-page pair in sync per repo convention.
• The renamed alerts.mdx file keeps a single H1 and all referenced anchors (#alert-setup, #alert-states, #automations, etc.) are defined in the file.
• The one issue surfaced (a pre-existing "spend alerts" vs. "alerts" naming overlap in the cost-management doc) is a wording nit already called out as an inline comment — it doesn't affect correctness of any link, redirect, or code path, so it doesn't warrant blocking this otherwise clean rename.