---
title: "Read the Usage Page"
description: "Learn the three-move diagnostic method behind every optimization in this course: find the driver in the team Usage tab, match the signal in Observability, and validate before changing anything."
canonical_url: "https://vercel.com/academy/optimize-your-vercel-account/read-the-usage-page"
md_url: "https://vercel.com/academy/optimize-your-vercel-account/read-the-usage-page.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-07-21T21:25:19.387Z"
content_type: "lesson"
course: "optimize-your-vercel-account"
course_title: "Optimize Your Vercel Account"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Read the Usage Page

# 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.

\*\*Note: What is the Usage tab?\*\*

The Usage tab is the team-level dashboard page that shows how much of each
Vercel product your projects consumed this billing cycle: function
invocations, data transfer, image transformations, ISR writes, and the rest.
Every chart breaks down by project.

## 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:

| Signal                                                 | Likely story                                  | Where we fix it            |
| ------------------------------------------------------ | --------------------------------------------- | -------------------------- |
| Function duration is high but the code barely computes | The function is waiting on something upstream | 3.1 Fluid Compute          |
| Lots of invocations, all producing the same answer     | Repeat work that should be cached             | 3.2 Runtime Cache          |
| ISR writes pile up while content never changes         | Revalidation on a timer nobody needed         | 3.3 ISR Writes             |
| Image transformations spike while traffic holds steady | Variant churn or a short cache TTL            | 4.1 Image Optimization     |
| Edge requests far outnumber page views                 | Speculative prefetching, or bots              | 4.2 CDN Requests, 2.4 Bots |
| Usage jumps the same hour as a deploy                  | A code change, not a traffic change           | Compare the deploy's diff  |

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

\*\*Note: Charts move around\*\*

Vercel regroups the Usage charts from time to time. If a chart isn't where
this lesson says, scan for the product name instead of the section heading.
The products themselves are stable.

## 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:

```bash
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.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)