Vercel added redirect and external-rewrite telemetry to its Observability product, exposing per-route metrics for edge routing logic that previously ran without any per-route signal. A misconfigured rewrite used to 404 or hang with nothing to trace; its volume, latency, and source-to-destination paths now sit in the same dashboard as function errors, which is enough to shift who gets paged when a redirect chain breaks.
What shipped, and when it became generally available
Vercel’s redirects-and-rewrites changelog entry, dated 2025-11-03, added external rewrites and redirects to Observability’s tracked traffic sources. The live Observability documentation, accessed 2026-06-28, confirms the feature is generally available across all plans: “External Rewrites” and “Microfrontends” both appear as tracked data sources at team and project level, alongside Vercel Functions, Edge Requests, Middleware, and the AI Gateway.
The “Microfrontends” data source is worth flagging because it was not in the original changelog announcement. Its presence in the current docs table is the main evidence the routing-visibility surface has expanded since November, though Vercel has not published a dated changelog entry explaining exactly what it tracks. Treat the November announcement as a floor, not a ceiling, on what Observability now instruments for routing, and check the live docs table before relying on a metric that may have been added quietly.
What can you see, and which tier shows it
Every plan, including Hobby, gets total external rewrites, external rewrites broken down by hostname, and errors by hostname and path, per the changelog. That is enough to know a rewrite is firing and where errors are clustering.
Observability Plus, available on the Pro and Enterprise tiers, adds the dimensions that turn the feature from a counter into a debugging tool: connection latency to the external host, rewrites broken out by source and destination path, and the routes and paths behind a redirect location. The changelog is explicit that this granular path-level detail is paid-tier only.
Why edge routing ran as a black box
External rewrites forward requests to APIs or websites outside the Vercel project, which lets Vercel act as a reverse proxy or a standalone CDN in front of an origin it does not control, per Vercel’s rewrites documentation. The same docs draw a deliberate line between this and same-application rewrites, which route within a single project and prefer framework-native routing.
That external-origin category is where the historical black box lived. A rewrite pointed at a misconfigured upstream, a destination that had moved, or an origin whose TLS had rotated would fail, and the failure looked like any other request that did not resolve: a 404 from nowhere, a timeout against a host that did not answer, a 502 handed back by the origin. Nothing in Vercel’s dashboards tied the failure back to the specific rewrite rule that produced it. The recovery path was reproduction: deploy a local copy, grep the vercel.json, or crawl log drains by hand.
The 2,048-rule deployment cap compounds this. Vercel caps static redirect and rewrite rules at 2,048 per deployment, per its redirect limits knowledge base article; once a project crosses that line, teams must move to bulk redirects, Edge Middleware paired with Edge Config, or Serverless Functions for dynamic behaviour. Each escape hatch changes the observability story. Middleware was already a tracked data source, so dynamic routing implemented there produced at least partial telemetry, while a static vercel.json rewrite emitted none. A project sitting close to the ceiling with rules spread across vercel.json and Middleware carries a large surface of routing logic that, until now, was only partially observable when it broke.
How does this change who owns a routing incident
When rewrite volume, latency, and error counts appear beside function errors in the same Observability view, a broken redirect chain can be triaged the same way a 500 from a Serverless Function is triaged. The on-call engineer does not need to know which rewrite rule is suspect, or who wrote the routing config, to see that an external origin is erroring and at what volume.
The practical shift is that routing incidents move toward whoever is on-call and away from whoever authored the vercel.json. Before this feature, a redirect failure was a “go find the person who set up the rewrites” problem, because the only person with a mental model of the routing table was the one who built it. Structured per-route telemetry externalises that model into the dashboard, so the responder on call can read it directly instead of waiting for the author to come online and explain which destination maps to which source path.
How log drains and the April 2026 caching default fit in
External origin events flow into runtime logs through log drains, so rewrite and proxy traffic can be exported alongside function logs rather than staying trapped in the Observability UI. The rewrites documentation describes an External Origins tab that surfaces request counts, connection latency, and traffic patterns for proxied requests, giving a view of upstream behaviour that previously existed only in the origin’s own logs. For teams already shipping Vercel logs to Datadog, Splunk, or a self-hosted store, rewrite traffic is now exportable on the same drain.
The caching story changed in April. For projects created on or after April 6, 2026, Vercel honours upstream cache-control, CDN-Cache-Control, and Vercel-CDN-Cache-Control headers on external rewrites by default, per the rewrites documentation. That default makes the upstream’s cache directives authoritative for rewrite traffic in a way they were not before. It now has matching Observability visibility: a rewrite caching aggressively, or refusing to cache because of a mis-set upstream header, shows up in the same dashboard as the traffic it serves. A new default and new visibility landed close enough together to be worth treating as one operational change rather than two unrelated releases.
What does this still leave unsolved
The feature instruments external-origin rewrites specifically, not all routing. Same-application rewrites, which route within a single project and are handled natively by Next.js and Vercel’s own routing, are a separate category and are not what Observability surfaces here. A team whose routing failures come from internal framework routing will not find them in the External Rewrites tab, and will still lean on Next.js’s own request logging and the existing Edge Requests data source.
Free-tier path blindness is the other gap. A Hobby-plan user gets hostname-level counts and error breakdowns but not the source-to-destination path detail that lives in Plus, per the changelog. On a project with dozens of rewrites hitting a handful of hostnames, that is the difference between “a rewrite is failing” and “this specific rewrite is failing,” and only the second is actionable without local reproduction.
Vercel’s framing of external rewrites as letting the platform act as a “reverse proxy or standalone CDN,” per the rewrites documentation, is the marketing layer over a narrower practical change: visibility into the proxy requests you were already making. The rewrites were always running. What changed is that the ones failing now appear next to your function errors, in a dashboard the on-call engineer already has open. Edge routing config is becoming a first-class observability surface, and the consequence is less about new capability than about who gets paged, and how fast a broken redirect chain gets traced.
Frequently Asked Questions
How does Vercel’s new rewrite visibility compare to Cloudflare Workers or Netlify?
Cloudflare Workers observability and Netlify redirect handling occupy comparable territory for routing visibility, but Vercel’s announcement does not position itself against either competitor. The differentiator Vercel claims is placement: rewrite and redirect metrics sit beside function errors in a single Observability view, so one on-call responder can triage both without switching tools.
Will redirects I moved into Edge Middleware appear in the External Rewrites tab?
Redirects moved into Edge Middleware land in the Middleware data source, and those moved into a Serverless Function land in Vercel Functions, rather than the External Rewrites tab that instruments static external-origin rules. Teams using dynamic escape hatches to avoid the 2,048-rule cap therefore see routing telemetry fragmented across multiple Observability surfaces.
What routing failures will still be invisible in the External Rewrites tab?
Same-application rewrites handled by Next.js framework routing are not instrumented here, and neither are correctness failures inside the origin itself, since Observability sees only the request Vercel proxies and the response it receives. A 200 from an upstream returning the wrong content, or a same-app rewrite pointed at the wrong internal route, will not appear in this tab.
Is it still worth converting static rewrites to Middleware now that Observability tracks them?
The calculus shifted. Before November, static external rewrites emitted no per-route signal in Observability while Middleware was already tracked, so pushing routing into Middleware was the only way to get any per-route telemetry. Now that static rewrites carry per-route signal in the External Rewrites tab, converting them to Middleware purely for headroom trades that unified view for telemetry spread across a different data source.
