Docs › Dashboard › Metrics

Metrics

The Metrics page (sidebar > Metrics) gives you a deeper analytical view of your usage. It holds one panel, Usage, which breaks your traffic into groups and puts the totals for the whole period above a page of rows.

For summary cards and timeline charts, use the Dashboard Overview page.

Product

The page opens on a Product switch: API for the requests you send to the API endpoints, Proxy for the tunnels your own tools open through proxy.foura.ai. Each product has its own Usage panel with its own views, scopes, and columns, because a tunnel has no request count and no credits. The switch is remembered and deep-linkable as #metrics/proxy.

Filters

Above the panel: Product, Endpoints (API only), Owner, then Key (API) or Proxy user (Proxy), then Period. Owner and Period are the same controls as on Overview and they share their state, so switching between the two pages never changes what you're looking at.

Owner Filter

Everything, Personal, or one of your organizations. It only appears once you belong to at least one. Picking an owner also rebuilds the Key and Proxy user dropdowns, so a credential from the previous owner can't survive the switch and silently return nothing.

Key and Proxy User Filters

Scope the page to a single credential. Only credentials you have access to appear: your own, plus those of organizations you belong to.

Period

Eight pills, 30M, 3H, 12H, 24H, 7D, 30D, 90D, and 1Y, plus Custom for a calendar month, the last 6 months, all time, or an exact pair of dates.

Endpoints

On the API product, pick Single, Proxy Finder, Browser, or Auto to scope the cards and the table to one endpoint. An Auto call counts once, under Auto. The Concurrency scope isn't available while an endpoint is picked.

The Usage Panel

The panel answers two questions at once. Cards above the table describe the whole period: how many groups it holds and the totals across all of them. The table below is one page of those groups, sorted by the column you pick.

The two are never about different traffic: the cards run the same window and the same filters as the rows. The group count is written out in full rather than rounded, because an exact number is an answer to "how many domains did we reach this month" and a rounded one isn't.

Changing the view, the scope, or the period starts the set again from the first page. Page 4 of domains is not page 4 of client IPs.

Click a column header to sort. On the API product's Domain and Client IP views, the sort runs over the whole list before it's cut into pages, so the top row really is the largest, and the table starts again from the first page. The API Key view holds every key on one list and sorts it in place. Sorting goes back to the scope's own order when you switch view or scope, or reload the page: the most requests first, or under Routes the most browser attempts by Auto. Ctrl or Cmd click a header to reset.

Usage, API Product

Three views:

View Groups data by
API Key Each key you have access to
Client IP Source addresses making the requests
Domain Target domains in your requests

Scope chips change the columns and the cards:

Scope What it shows
Bandwidth Request count, bytes in, bytes out, and the premium share of those bytes (traffic served through a premium exit, inside the totals rather than added to them)
Response Time Request count, min, average, max latency
Concurrency Request count plus concurrent request counts (API Key view only)
Outcomes Request count plus a per-outcome breakdown, with the outcome donut
Budget Request count and credits spent, every outcome included. To see one endpoint, pick it in the Endpoints row
Routes Request count, your requests per route, what Auto ran behind its calls, and the step that answered each Auto call (see below)

The Budget scope reads the credits metric the API reports on every request (see Response Headers). Those sums are the raw metered spend. Billing counts only the success outcome against your plan, and the Overview Credits card shows both side by side.

Routes Scope

Routes splits the requests of each key, client IP, or domain by route and shows what Auto did for its calls. Its columns come in three groups, each with a caption above it:

Group Columns What they count
Requests by route Single, Proxy Finder, Browser, Auto Your requests, by the route you sent them to. Together they make Requests. An Auto call counts once, under Auto. Under each number: its share of Requests.
Auto attempts Single, Proxy Finder, Browser The requests Auto ran on each engine behind its calls, failed ones included. Under each number: attempts per Auto call.
Auto answered by Saved session, Plain request, Proxy Finder, Browser, Failed The step that delivered each Auto call. Together they make Auto. Under each number: its share of Auto.

Saved session is a session Auto already had for the host. Browser includes the calls where a browser opened the page first and a replay of its session delivered it. Failed includes calls refused before Auto ran.

To see where Auto uses a real browser, read the Browser column under Auto attempts. A browser usually opens a page once, and Auto then reuses that session with lighter requests, so this column is usually far larger than Browser under Auto answered by. Routes opens sorted by it, so the domains that need a browser most come first; groups with no browser attempts follow by request count.

The cards above the table show the Auto attempts in the period with the attempts per Auto call, and every browser opened, directly or by Auto.

Auto attempts never count in Requests or the success rate. They do count against the Single, Proxy Finder, and Browser rate and concurrency limits of your plan, as on the Overview's Auto attempts card. With an endpoint picked in the Endpoints row, Routes shows that route only: Browser then lists the browser requests you sent yourself, and the ones Auto ran stay under Auto.

Outcome Donut

Under the Outcomes scope, a donut sits inside the panel and shows the success and error breakdown for the selected period. Hover any slice for the exact request count and percentage. It's drawn only under that scope, since a picture of the whole window on top of a table answering a different question reads as two unrelated things.

Usage, Proxy Product

Five views:

View Groups data by
Proxy user Each proxy user you have access to
Target The host each tunnel reached
Exit country The country the tunnel left from
Client IP The address the connection came from
Outcome Outcome and its reason

Four scopes:

Scope Columns
Traffic Tunnels, Bytes In, Bytes Out, Premium
Setup Tunnels, Setup Min, Setup Avg, Setup Max, Duration Avg, Duration Max
Outcomes Tunnels plus one column per outcome, with the outcome donut
Budget Tunnels, Standard, Premium, Total

Setup is the wait before a tunnel was handed over. Duration is how long it then stayed open. Premium is the part of the traffic that left through the premium network, counted inside the total and never added to it.

No scope has a credits column or a request count. What travels inside a CONNECT is your own encrypted traffic, so the port counts tunnels and bytes and nothing else.

Outcome Types

Every API request is classified into exactly one outcome. Only success is billed.

Outcome Layer Meaning
success n/a The request delivered a valid response. With no validate rules, that means HTTP 200. With validate rules, any response your rules accepted, whatever the status.
application_error target The target returned HTTP 200, but the body carried an error field.
application_fail target The target returned a non-2xx your validate rules didn't accept, or no response at all.
client_error caller Your request was rejected before it left FourA: bad parameters, a malformed proxy value, or a URL that resolves to a private or reserved address.
rate_limit FourA The request was rejected by your RPM or concurrency limit. See Rate Limits.
service_error FourA The engine answered with a server error, or with a body we couldn't parse.
service_fail FourA A network failure: timeout, connection refused, DNS error, client disconnect.

The layer column tells you who's responsible. target means the site you called, caller means your request was bad, FourA means we couldn't process it.

If you use validate.status.accept to allow specific non-200 codes (for example [200, 403]), those come back as success instead of application_fail. The classification follows the engine's verdict on your rules, not the raw HTTP code.

A tunnel through the proxy port is classified into the same vocabulary, minus the two target outcomes: a tunnel's answer is your own encrypted traffic, so FourA never sees whether the site behind it was happy. For the full taxonomy and how it maps to billing, see Request Outcomes.

Last updated: October 12, 2026
← Managing API Keys Activity Log →