Seeing your Gateway traffic: a tour of the Portal

Once a team's model traffic goes through one gateway, the questions change. People ask why the bill jumped on Tuesday, which feature or customer is doing the spending, and whether a provider is slow right now or it's just them.

Every Gateway request is logged with its key, model, provider, status, latency, time to first byte, tokens and cost, even when you don't capture prompts and responses. Here is where the Tempr Portal answers each question.

"What does this week look like?"

The Gateway's first page is the Dashboard. It shows requests, cost, error rate, latency, time to first byte and tokens for the range you pick, with charts over time. The range runs from the last 24 hours up to your plan's log retention, which is 7 days on Free, 30 on Pro and 90 on Scale, or any dates you choose inside that.

Below the headline figures are the breakdowns: top models, providers, spend by key against each key's budget, prompt caching, guardrails and prompt templates. You can filter the whole page by key, provider or model.

On Pro and up, each figure also shows its change against the period before.

For a team on one Gateway plan, Team gateway is the same dashboard over the organization's keys.

"Why did cost jump on Tuesday?"

The Dashboard shows the jump. The log explorer finds it. Logs take a time range and filters by key, provider, model, session, end user, operation, duration, a metadata entry or a request ID. Status is in plain words, so you filter for "rate limited" or "blocked by guardrail" rather than a code.

Each active filter shows as a chip you can remove, and every view has its own address. Narrow it to Tuesday afternoon and one key, paste the link to a colleague, and they see the same list. Export CSV exports exactly what's shown, with cost, session, end user and metadata in the file.

If the jump came from agent work, the Usage page lists the month's most expensive agent runs: when each started, who ran it, its model, how many model calls it made and its cost, sub-agents included, with a link to its trace. An organization's owners and admins see it on the Budget page.

"What actually happened to this request?"

Opening a request shows its request page. It records the model you asked for and the one that answered, which aren't always the same: a fallback alias resolves to a real model, and a fallback chain can move on to the next one. The page lists every model and provider key tried on the way, so you can see when a request only got its answer after the first try failed.

It also shows the prompt and response caches, the request's cost and the reasoning level applied, and its key, session, end user, prompt template and metadata, each linking onward.

A key's Stats link, on Gateway keys and Org keys, opens the Dashboard for that key, headed by its status, budget spent, limits, allowed models and expiry.

"Which feature, or which customer, is spending?"

Only your code knows which feature made a call or which customer it was for. The x-tempr-metadata header carries that. It's a small JSON object stored with the request's log:

x-tempr-metadata: {"feature": "search-summary", "customer_id": "acct_123"}

The Metadata page groups your requests by any key of that object and shows each value's requests, cost, error rate, median and p95 latency and tokens, each linking to its logs. Group by feature to see what each feature costs, or by customer_id for each customer. A team's Metadata view is on its Team gateway page.

Two more groupings come from the request itself. Send x-tempr-session-id and a conversation's or agent run's requests show together under Sessions. The request's own end-user field (safety_identifier or user, or metadata.user_id on /v1/messages) fills End users. Both chart their ten costliest, and a session's page charts its requests in order, with failures in red. The details are under request logs in the Gateway reference.

"Is this provider slow right now?"

Filter the Dashboard by provider and look at latency and time to first byte over the last 24 hours. Alert rules answer it when you aren't looking.

On Gateway Pro and up, the Alerts page sets rules on the error rate, cost, cost against the usual, p95 latency or number of requests, looking back over the last 15 minutes, 1 hour, 6 hours or 24 hours. A rule can watch all your keys, or one key, provider or model. Some details:

• A request rule can alert when the count falls below its threshold, which catches traffic that stopped.
• Error rate and p95 latency wait for a minimum number of requests, 20 unless you change it.
• "Cost against the usual" compares the window's cost with the average for a window that long over the previous 7 days.
• A rule notifies once when it's crossed and once when it recovers, by email (to you, or to a team's owners and admins), by webhook, or both. The Dashboard shows any rule that's firing.

The webhook sends gateway.alert.triggered and gateway.alert.resolved with the rule, its threshold and filters, the value, and a link to the Dashboard with the same filters applied. Events are signed; alert webhooks shows the payload and how to check the signature.

Below Pro, two fixed webhook alerts are available in Settings instead: one for error rate and one for cost anomalies. On Pro and up they become your first two rules.

"How did last week go?"

The weekly report is an email each Monday with the week's requests, error rate, cost, tokens and latency, the top models and keys by cost, and the change from the week before where your log retention still covers it. New Gateway accounts get it instead of the daily digest, and you can turn either on or off in Gateway settings.

When the answers belong in your own tools

On the Enterprise plan, an organization's owners and admins can set up log streaming: request logs and agent traces go to an OpenTelemetry endpoint as spans as they happen, and the audit log goes there too or to a signed webhook. A destination gets what happens from the moment it's added, not what came before. See log streaming.

Where to start

All of this works from logs the Gateway already keeps. The one thing worth adding early is the metadata header: requests sent without it can't be grouped by feature or customer later. The Gateway page has screenshots of the Dashboard and logs, and pricing shows each plan's log retention.