What happened
Vercel’s Observability Insights documentation organizes analytics into sections corresponding to product features and traffic sources. Alongside views for Vercel Functions, external APIs, middleware, CDN requests, image optimization, builds, and other services, it documents an AI Traffic tab. The stated purpose of that tab is to show how AI bots interact with a site.
The AI Traffic view charts requests from AI bots over time. It separates two categories: AI crawlers that index or train on content, and AI assistants that fetch pages on behalf of a user. That distinction matters operationally because the two types of requests imply different kinds of access. A crawler may be collecting or indexing pages broadly, while an assistant request is described as fetching a page in a user-initiated session. The page does not say that either event demonstrates that a model understood, cited, ranked, or relied on a page.
The documentation lists four further views within the AI Traffic surface. Operators can see the paths AI crawlers request most often; the paths AI assistants request most often from user-initiated sessions; paths requested by AI bots that received an error; and paths AI bots request as Markdown. These are path-level access signals. They can help distinguish broad crawler interest from assistant retrieval, identify routes failing for AI-bot traffic, and spot requests for a machine-friendly representation of a page.
Vercel also says that AI crawler, AI assistant, and failed-request counts can be queried through AI traffic metrics in the Vercel CLI. This gives teams a command-line route to the three count categories rather than restricting them to the product interface. The same documentation says the CDN Requests tab includes detailed breakdowns for individual bots and bot categories, including AI crawlers. For Observability Plus users, Vercel lists additional controls: filtering traffic by a bot category such as AI, viewing metrics for individual bots, and breaking down traffic by bot or category in the query builder. The source gives no release date, pricing figure, quota, or statement that this page marks a newly launched capability.
What the archive adds
This is a new fact on a known Vercel Observability story rather than a wholly new event. Vercel Observability adds AI traffic insights showing how AI bots crawl and request pages covered the AI-specific analytics surface. The current documentation adds the explicit crawler-versus-assistant distinction, Markdown-request visibility, failed-request counts in the CLI, and the stated Observability Plus controls.
Vercel Observability adds custom monitors with threshold and anomaly alerts is related at the product level: it described query-based monitoring and alerts, while this documentation describes traffic dimensions that an operator may inspect. The source does not say those features are preconfigured together.
Trend signal
This supports agent-ready software exposes capabilities. External AI systems are becoming a traffic class that site operators can observe through categories, paths, failures, and format requests rather than treating machine access as invisible background activity. The evidence is narrower than the pattern’s full claim: Vercel documents observability, not a permission system or a general capability interface for agents.
Why now
The supplied source does not date the AI Traffic documentation or explain a launch timetable. What is clear is the operational context: AI crawlers and user-facing assistants can request the same site through different paths and for different purposes. A dashboard that separates those requests makes that distinction inspectable when teams are already responsible for route health, errors, and traffic analysis.
Connections to other events
An earlier Field Note, Vercel Sandbox now has memory observability., treated sandbox memory as an operational signal rather than an opaque execution constraint. This item applies a related observability move to the web boundary: requests from AI systems, their requested paths, and their failures become visible signals. The two sources concern different Vercel products and do not establish a shared implementation.
Why it matters
Teams operating documentation, product, or application sites increasingly have a second audience beyond conventional human visitors: systems that crawl pages and assistants that retrieve them while helping a user. Combining all of that activity into a single traffic number makes diagnosis harder. The documented separation between crawlers and assistants gives operators a more useful starting point for investigating whether a route is broadly discovered or fetched during user-driven retrieval.
The path lists can direct basic checks: are important pages reachable, do recurring requests return errors, and are bots asking for Markdown? CLI-queryable counts also make it possible to incorporate access checks into an existing operational workflow rather than relying solely on a dashboard. The practical constraint is access level. Vercel specifically assigns bot-category filtering, individual-bot metrics, and query-builder breakdowns to Observability Plus users. Teams should therefore verify which controls their plan exposes before designing a monitoring process around them. Earlier coverage: Vercel Observability adds AI traffic insights showing how AI bots crawl and request pages.
What happens next
- More operators will add AI-bot request categories to routine web-access investigations. (6 months, 60%). Watch for: AI crawler and assistant metrics appearing in operational runbooks or alert queries.
- Teams using the documented views will test error-prone and Markdown-requested paths first. (3 months, 65%). Watch for: route fixes or content-format changes tied to those path lists.
Limits and uncertainty
The source is product documentation, not a dated release announcement or an independent evaluation. It does not establish when the views or CLI metrics became available, how many customers use them, or whether they improve indexing, retrieval, citations, conversions, or assistant answer quality. It provides no prices, quotas, retention periods, bot-identification methodology, classification accuracy, or completeness guarantees.
A request attributed to an AI crawler or assistant only records access as Vercel defines it. It does not reveal what happened after retrieval, whether a user saw an answer, or whether the content affected a model response. The page also does not name the individual bots represented in the AI Traffic view, beyond describing available categories and bot-level controls in CDN Requests for eligible users.
Skill to build now
Create a short access-check list for the pages that matter most to an AI-facing site: core documentation, pricing or product pages where relevant, and any machine-readable endpoints already offered. In Vercel, inspect the AI Traffic path and error views, then query the documented crawler, assistant, and failed-request counts through the CLI. Treat a repeated error as a web-access issue to reproduce and fix, not evidence that an AI system is malfunctioning. If Markdown requests appear, confirm that the requested representation is intentional and functional.
Reader takeaway
Vercel documents a practical visibility layer for AI-related site requests. It can show whether crawlers or user-facing assistants request particular paths, which requests fail, and when Markdown is requested; selected counts are also available through the CLI. Use it to diagnose access and route health, not to infer AI comprehension or business impact.
Open question
How Vercel identifies and classifies individual AI crawlers and assistants, and how long these traffic records are retained, is not established by the supplied documentation.