Serve analytics
What /serve/analytics shows + how it's computed.
What you see
| Section | Metrics |
|---|---|
| Activity | Total requests · Unique agents · Avg payload size · Edge latency |
| What Onto saved your bots | Payload bytes saved · Estimated tokens saved · Estimated $ saved (at GPT-4o input rate, $2.50/1M tokens) |
| Timeline | Daily request count, last 7 days, line chart |
| Bot breakdown | Bar chart of requests per agent (GPTBot, ClaudeBot, PerplexityBot, etc.) |
| Top routes | 5 most-hit routes with a horizontal usage bar |
| Recent events | Last 8 bot hits with timestamp + agent + route |
Where data comes from
Two tables: agent_events (one row per tracked bot hit, written by /api/track when the SDK middleware fires) and onto_files (per-route byte counts, written by the build CLI). The dashboard joins them at query time so payload-saved values are derived from the latest build's actual file sizes × actual hit counts — no stale byte numbers from old SDK versions.
Sampling caveat
Telemetry is sampled by default. Vercel's CDN caches the served
.md files for ~1 hour. When a request hits cache, our middleware doesn't run — so it can't fire a telemetry POST. In practice you see roughly one event per (route × bot) per hour, not one event per actual hit. Counts are directionally accurate for trends but underestimate raw volume.To extrapolate: if your /serve/dashboard shows N events/day on a route and the cache TTL is 1 hour, real hits ≈ N × 60 in the worst case. The dashboard values shown are conservative.
Retention by plan
| Serve plan | Analytics retention |
|---|---|
| Free | 30 days |
| Pro | 1 year |
| Business | Unlimited |
| Enterprise | Unlimited |
Enforced at query time — older events aren't deleted, just filtered out for Free/Pro. Upgrade to surface historical data without a re-import.