DEV Community: galb

How to see Vercel Web Analytics for all your projects at once

galb — Sun, 25 Oct 2026 14:30:54 +0000

If you have more than a few projects on Vercel, you know the routine: open a project, click Analytics, note the numbers, go back, open the next one. Vercel shows Web Analytics one project at a time.

In May 2026 Vercel made its Web Analytics API public. This post shows how to use it to get the numbers for every project, and what you have to build around it.

The API in two minutes

There are two datasets:

Visits: page views tracked automatically, with pageviews and visitors.
Events: custom events sent with track(), with count and visitors.

Each dataset has two queries:

Count (/v1/query/web-analytics/visits/count) returns one total.
Aggregate (/v1/query/web-analytics/visits/aggregate) returns rows grouped by up to two dimensions in by. One can be a time unit (hour, day, week, month, year). The others include country, referrerHostname, requestPath, deviceType, browserName and the UTM fields.

You authenticate with a normal Vercel access token. You pass a projectId, plus teamId for team projects.

Visitors and page views for one project over a week:

curl --get "https://api.vercel.com/v1/query/web-analytics/visits/count" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  --data-urlencode "teamId=team_1234567890" \
  --data-urlencode "projectId=prj_1234567890" \
  --data-urlencode "since=2026-10-05" \
  --data-urlencode "until=2026-10-11"

For a chart, ask the aggregate endpoint for one row per day:

curl --get "https://api.vercel.com/v1/query/web-analytics/visits/aggregate" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  --data-urlencode "teamId=team_1234567890" \
  --data-urlencode "projectId=prj_1234567890" \
  --data-urlencode "since=2026-10-05" \
  --data-urlencode "until=2026-10-11" \
  --data-urlencode "by=day"

The catch: one project per request

projectId is required on every query. To see all your projects, you build the rest yourself:

List the projects. Call the projects API for each team, page through the results, and skip projects without Web Analytics.
Make several queries per project. Totals, a daily series, top referrers and top countries are separate calls. At five calls per project, 100 projects cost about 500 calls.
Query the previous period too. "Up 12% on last week" needs the same queries again for the week before. That period must be inside your plan's reporting window: 1 month on Hobby, 12 months on Pro, 24 months with Web Analytics Plus or Enterprise.
Respect rate limits. The docs don't state a limit. In our tests, responses carried x-ratelimit-limit: 400 with a reset about a minute later. A large team needs a queue, backoff on 429, and a cache.
Mind time zones. In our tests, time buckets were in UTC and the API had no time zone parameter.
Keep one token per team. A team-scoped token sees one team, so agencies keep several. In our tests, personal access tokens worked, but integration tokens got 404 from the Web Analytics endpoints.

For a one-off answer: the CLI

vercel metrics queries the same data from a terminal. With --all and --group-by projectId it covers every project in the current team. It's a good fit for a question you ask once. It isn't a dashboard someone else can open.

Or use Lookout

I hit this problem with my own projects, so I built Lookout. It's the script above, finished:

Every project's visitors, page views and pages per visit on one board, against the previous period
Compare up to five projects on one chart
A read-only share link per board for clients, with no Vercel seat
Email alerts when a site spikes or drops, and a TV mode
An open-source MCP server, lookout-mcp, so Claude or Cursor can answer "which of my sites grew this week?"

You paste a Vercel token scoped the way you choose, and Lookout caches results and handles the rate limits. There's a live demo that needs no sign-up.

Whichever way you go, I'd like to hear how you track several Vercel projects today. Leave a comment.

Agents misread Hebrew. A 40-year-old aerospace standard helps.

galb — Thu, 22 Oct 2026 07:04:16 +0000

In aerospace maintenance, a misread instruction can ground an aircraft, or cause worse damage. So the industry built ASD-STE100, Simplified Technical English. It is a controlled language with one meaning per word, active voice, short sentences, and one instruction per sentence.

Today a new kind of reader parses technical text with no one to ask: the AI agent. A model reads tool descriptions, error messages, and instructions between agents. It cannot ask the author what the author meant. danyuchn/asd-ste100-skill applies STE100 to English agent text as a Claude Code skill. I ported it to Hebrew.

Why Hebrew needs its own rules

STE100 defines English only. No official Hebrew version exists, so every Hebrew rule here is an adaptation. Some English rules carry over directly. Others have no English equivalent:

Keep את. Headline-style Hebrew drops את before a definite object: "למחוק קובץ ההגדרות". Keep it: "למחוק את קובץ ההגדרות". Then the direct object is explicit.
Put a hyphen before Latin text and digits. In "בשרת הAPI", the prefix merges into the term. Write "בשרת ה-API".
Use one instruction form. Hebrew procedures often mix the imperative ("פתח"), "יש ל-", and the future tense ("תבדוק"). The skill uses the infinitive ("לפתוח") for every instruction. The infinitive is also gender-neutral.
Use one part of speech per word. In "המשתמש משתמש בכלי", משתמש is both "user" and "uses". Keep it a noun and use a different verb: "המשתמש מפעיל את הכלי".
Do not use לבצע with an action noun. "לבצע בדיקה של המסנן" hides the action in a noun. Write "לבדוק את המסנן".

The most important rule: hedges stay hedges

Before:

ייתכן שאירעה שגיאה במהלך עיבוד הבקשה שלך עקב אי-התאמה אפשרית בפורמט הנתונים הצפוי, אשר עשויה להיגרם כתוצאה מגרסת לקוח שאינה מעודכנת.

After:

ייתכן שאירעה שגיאה בעיבוד הבקשה. ייתכן שהסיבה היא אי-התאמה בפורמט הנתונים הצפוי. ייתכן שגרסת לקוח לא מעודכנת גרמה לאי-ההתאמה הזו.

"אירעה שגיאה" ("an error occurred") reads better. But it states an error that the system only suspects. A simplifier that removes uncertainty makes the text clearer and wrong. The skill splits the sentence into three claims and keeps every hedge.

Two modes and a linter

Strict mode is for procedures, error messages, tool descriptions, and agent instructions. It applies every rule, including the length limits.
Flavored mode is for README prose. It removes marketing words that have no measurement, and it keeps every claim.

A Python linter (scripts/ste-lint-he.py) uses only the standard library. It does a mechanical first pass: semicolons, sentence length, nominalization, marketing words, prefix hyphens, slang, and synonym rotation. It cannot check construct chains, homographs, or a dropped את. The model and the author check those.

Try it

npx skills add g4lb/asd-ste100-hebrew-skill

Then ask Claude: פשט את תיאור הכלי הזה ("simplify this tool description").

Repository (MIT license): https://github.com/g4lb/asd-ste100-hebrew-skill

If you write Hebrew for agents, tell me which rules feel wrong.