> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hopscotchlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# View activity
> Every request as a row: what happened, what it cost, how to open one request, and exactly what is kept about it.
Activity lists every request this workspace has made, newest first, one row per
request. Everything below, the columns, the filters and the single request view, is
what the shipped screen shows today.
## The columns, in order
| Column | What it shows |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| When | When the request started, in UTC. |
| Door | `api` or `playground`. |
| Model | The model that was asked for. |
| Served by | The provider that answered, or **nothing** if none did. |
| Outcome | A plain word: **served**, **provider error**, **refused**, or **other** for anything newer than the list the screen knows. The exact code is kept on the single request view. |
| Tokens | The total token count, or **unknown** if none was ever reported. |
| Charge | What the request cost, as dollars to as many places as the figure needs and never fewer than two, or **unpriced** if the request was never priced. |
| Took | How long the request took, in milliseconds. |
| Request id | The first eight characters, linking to the single request view. |
## Reading a row
**Outcome reads as a word, and the code is still there.** A row says **served**,
**provider error** or **refused**, and a row that is not served is drawn in a distinct
color to draw the eye. Those three cover the whole outcome vocabulary the platform
records; a code newer than the list this screen knows reads **other** rather than
disappearing or being filed under the wrong one. The exact code the platform recorded
is on the single request view, which is where a support thread needs it.
**`unknown` is not zero.** A token count that was never reported reads `unknown`; a
count of zero is printed as `0`. Those are different facts: a provider that never
told us how many tokens it used is not the same as a request that genuinely used
none, and collapsing them would turn an outage into a page of free requests.
**`unpriced` is not free.** A request with no charge figure reads `unpriced`; a
charge of `0` is printed as money. Only a request that was actually priced at zero
shows a zero.
**A failed or refused request is an ordinary row.** It is not hidden, not grouped
separately, and not given its own table. It carries the same nine columns as every
other row, colored to stand out by its outcome, with its tokens and its charge
following the same rules above: a refusal you were not charged for shows `unpriced`
or a real `0` depending on what actually happened, never a blank.
## Filter by model, outcome and date
The filter panel offers four controls, and they compose: every one narrows the same
list.
| Filter | Options | Default |
| ------- | -------------------------------------------------------------------------------------------------- | ----------- |
| Model | Only the models this workspace has actually called, each named the way the catalog names it today. | Any model |
| Outcome | One of four choices: any outcome, served, provider error, refused. | Any outcome |
| From | A calendar date. Inclusive, applied to when the request started, in UTC. | Empty |
| To | A calendar date. Exclusive, applied to when the request started, in UTC. | Empty |
Beside the date fields are shortcuts for the last day, the last week, the last month
and all time. A shortcut writes the two date fields and applies at once.
The narrowing lives in the address, so a filtered view survives a reload and a back
button and can be pasted into a support thread. A value the screen cannot read is
dropped and named rather than silently ignored, because a filter that quietly does
nothing shows you more rows than you asked for and they read as rows inside the
filter.
**Choosing a model still finds rows written under an older name.** A model that has
been renamed is one entry in the list, and choosing it matches the requests recorded
under every spelling that folds into it. You do not have to know what the model used
to be called.
There is no request id filter. One request id has one page, so the way to reach it
is to click the truncated id in a row rather than to type it into a narrowing
control. See [Look up one request](#look-up-one-request) below.
## How many rows to a page
The rows-per-page control offers 25, 50 and 100, and opens on 25. Your browser
remembers the choice, so it survives a reload on the same machine and does not follow
you to another one. Rows are ordered by time with the request id as a tiebreak, so a
row cannot land on two pages, or on none, between one read and the next.
## Three ways to see no rows
They mean different things, and the screen says which:
1. **Nothing has ever run here.** The workspace is new. The screen reads: "Send a
request from the playground, or with an API key, and it appears here with its
tokens, its outcome and what it charged. We never store the prompt or the
answer."
2. **The filter matched nothing.** Rows exist; this narrowing excluded all of them.
The table keeps its shape and offers a control to clear the filter.
3. **The range reaches further back than we keep.** It was never going to answer,
so the screen names the retention window instead of inviting a narrower filter.
## How far back activity goes
The window in force is 90 days, over a floor of 62 days: the least this platform
will ever keep, and the longest pair of calendar months back to back. A range that
reaches past that horizon is the third case above, "the range reaches further back
than we keep," not an empty table.
Money outlives the row. When a request passes out of this window, the charge it
caused stays on your statement even though the row describing the request is
gone.
## Look up one request
Click the request id in any row to open the single request view. It repeats the
same facts as the row it came from, in full:
* the complete request id
* When, Door, Model, Served by, Outcome
* Streamed: **yes** or **no**
* Prompt tokens, Completion tokens, Total tokens
* Charge
* Took
Some requests carry an explanatory note beneath the figures, written by the
platform rather than by the screen. Every lookup also shows when the figures were
read, separately from when the request itself ran.
A request id from another workspace and a request id that never existed answer
identically: neither is found. That is deliberate. The lookup cannot be used to
learn whether an id exists somewhere you cannot see.
## What is never on the row
The single request view says it in as many words: no prompt and no response body
was ever stored for that request, so the fields above are everything that exists.
Nothing is truncated, sampled or hashed instead; there is nowhere in the record for
either one to go, so there is nothing more to look up no matter who asks.
What is kept is exactly the metadata columns above: when a request ran, which door
it came through, the model and provider, the token counts, the charge, how long it
took, and the outcome. See [Data and privacy](/concepts/data-and-privacy) for the
full statement, which this page does not repeat further.
## Next
Read what the workspace has spent, and reconcile a statement line with the
request that caused it.
What is recorded about a request, what is not, and how long it is kept.
Every response carries the same id on two headers: `x-hopscotch-request-id`,
which is ours, and `x-request-id`, which is the one the official OpenAI SDKs
surface on their error objects. Every error envelope repeats it as
`request_id`. Quote it when you ask us about a request. Without it we are
guessing at which of your requests you mean.