Read the Usage Page

The first time a Vercel bill surprises you, everyone on the team has a theory. It was the marketing launch. It was that new hero video. It was bots. Theories are free, and that's about what they're worth.

The Usage tab settles arguments. It knows which product moved, which project moved it, and when. Every lever in this course, from Fluid Compute to image cache TTLs, starts with reading that page and following one number down to a route.

Saturday is a day old and has no bill to speak of. Perfect. Let's learn to read the gauges while they're at zero, so when a number moves later you'll know which one, and why.

Outcome

You can trace any usage number from the team Usage tab down to the product, project, route, and time window driving it.

The method

Every optimization in this course follows the same three moves:

1. Find the driver. Open the team Usage tab. One product is usually responsible for most of the movement, and within that product, one project.
2. Match the signal. Open that project's Observability tab and narrow to the window where the number moved. Find the route. The shape of the metric tells you what kind of problem you have.
3. Validate before changing anything. Confirm with a second signal. Does the deploy timeline line up? Is the traffic bots? Did the cache hit rate change? Then change one thing.

A few shapes you'll learn to recognize, and where this course handles each one:

Don't memorize the table. Memorize the moves. Driver, signal, validation.

Hands-on exercise 1.3

No settings change in this lesson. You're building the habit of reading before touching.

Requirements:

1. Open your team's Usage page. It's team-level, not project-level: from your team's dashboard, open Usage.
2. Identify the top product by usage for the current billing cycle, and the top project under it. On a fresh account the numbers will be tiny. That's fine. You're finding the numbers, not judging them.
3. Generate some traffic to Saturday: browse the homepage, the drops page, and a couple of product pages, then run the stock-check loop from Try It below.
4. Open Saturday > Observability > Functions and find the route your traffic drove to the top.
5. Write down the full chain: product, project, route, time window, cause. That's a driver trace, and it's the artifact this lesson produces.

Implementation hints:

• If you're staring at Saturday's project page and can't find Usage, you're one level too deep. Usage belongs to the team, because bills belong to the team.
• Every chart on the Usage tab clicks through to a per-project breakdown. That click is move one of the method.
• On Hobby, the Usage tab shows your included allotments and how much of each you've used. You don't need a paid bill for the page to be worth reading.
• Observability updates within minutes. Usage aggregates on a slower, billing-oriented cadence. When the two disagree, Observability tells you what just happened and Usage tells you what you'll pay for.

Try It

Send Saturday thirty stock checks:

for i in {1..30}; do
  curl -s -X POST https://YOUR_DOMAIN/api/stock-check \
    -H "Content-Type: application/json" \
    -d '{"sku":"sat-foundry-onyx","size":10}' > /dev/null
done

Now open Saturday > Observability > Functions and filter to the last 30 minutes. You should see your loop:

Path                      Invocations   Avg Duration
/api/stock-check          30            805 ms

Then step up to the team Usage tab and find Function Invocations. Saturday's count should tick up by about thirty, though it can lag Observability by a while. If the chart hasn't moved yet, check back after your coffee.

That's a complete trace, top to bottom: Function Invocations is the product, saturday is the project, /api/stock-check is the route, the last half hour is the window, and the cause is you, holding a curl loop.

Done-When

• You can get from any dashboard page to the team Usage tab in under ten seconds
• You've named the top product and top project for the current billing cycle
• Your thirty stock-check invocations are visible in Observability > Functions
• You've written one full driver trace: product, project, route, window, cause

Troubleshooting

The Usage tab shows zeros everywhere.

A fresh team with one day-old project barely registers, and some charts only render once there's something to show. Generate the Try It traffic, wait a bit, and check again. Zeros on day one are a feature.

Observability shows my invocations but Usage hasn't moved.

Expected. The two surfaces update on different clocks. Observability is near-real-time; Usage rolls up on a billing cadence and can run behind by minutes to hours. If Observability has the data, your trace is done. Usage will catch up.

The Usage breakdown lists projects I don't recognize.

That's the audit working already. Old previews, abandoned side projects, and that thing you deployed in 2024 all consume quietly. Note them down. Section 5 covers retention policies, and the skill in Lesson 4.5 can audit the ones you decide to keep.

Solution

There's no code. The deliverable is the trace, written down. Here's Saturday's:

Driver trace / saturday
Product:   Function Invocations
Project:   saturday
Route:     /api/stock-check
Window:    last 30 minutes
Cause:     me, with a curl loop
Action:    none needed. When it's drop-day bots instead of you,
           Section 2 has the firewall.

Five lines. It looks almost too simple to matter, and then a bill moves and it's the difference between a meeting full of theories and a one-line answer.

You can read the gauges. Now let's start locking things down.