The Activity tab on the API Keys page shows every API request made with any of the organization's keys. It's a per-request audit log - what was called, by which key, from where, how long it took, and what the response status was. Use it to verify a deployment is using the key you expect, hunt down a failing CI job, or investigate a key you suspect of being leaked.
Only owners and admins see the Activity tab. Other roles see only the Keys tab on the same page.
Before you start
- You need an owner or admin role on the organization. The tab is hidden for billing, technical, and read-only members because request paths and IP addresses are sensitive.
- Activity is retained for 30 days. Older requests have aged out.
1. Open the API Keys page
- In the sidebar on the left, click API Keys under your organization.
- The API Keys page opens.
If you don't see the link, you don't have the right role to view it.
2. Switch to the Activity tab
At the top of the API Keys page, the Keys and Activity tabs sit side by side. Click Activity.
The tab loads with three sections, stacked top to bottom:
- A Requests chart showing request volume over time, split by success / error.
- A Top endpoints chart showing which paths are being hit most.
- A Requests table listing the individual requests.
The charts and table all share the same set of filters above them - change a filter and everything refreshes together.
3. Pick a time range
Above the charts is a row of range pills: 1h, 1d, 1w, 1m. They control the window for everything on the tab.
- 1h: last hour, bucketed every 5 minutes.
- 1d: last 24 hours, bucketed per hour.
- 1w: last 7 days, bucketed every 6 hours.
- 1m: last 30 days, bucketed per day.
The selected range is highlighted. Changing it reloads the charts at the new resolution and reloads the table to that window.
4. Read the Requests chart
The top chart shows request volume over time as a stacked area:
- Green: 2xx / 3xx responses (successful or redirected).
- Red: 4xx / 5xx responses (errors).
Hover over the chart to see the exact counts for that bucket. The bucket size matches the range you picked (5 minutes for 1h, an hour for 1d, etc.).
If the chart is empty, no requests have been made in the selected window - try widening the range.
5. Read the Top endpoints chart
The second chart is a horizontal bar chart of the most-called endpoints in the selected window.
- Each bar is one endpoint (route path, like /vps or /billing/invoices).
- The length of the bar is the request count.
- Hover for the exact number.
This view is good for spotting which integration is doing what - a Terraform plan looks very different from a Datadog poller.
6. Filter the table
Below the charts is the per-request table with two filter controls above it.
Search
The leftmost control is a search box with a magnifying-glass icon. It searches across:
- HTTP method (GET, POST, PATCH, DELETE)
- Request path (/vps, /billing/invoices/inv-…)
- Key name (the friendly name you gave the key when you created it)
- Status code (200, 404, 429)
Type any text and the table narrows live, debouncing your input so you don't have to wait between keystrokes. Empty the box to clear the filter.
Status filter
To the right of the search box are four status pills: All, 2xx, 4xx, 5xx. Click one to limit the table to requests whose status code falls in that range.
- All: every request (default).
- 2xx: successful responses.
- 4xx: client errors (bad input, missing auth, rate-limited, not found).
- 5xx: server errors (rare; flag these to support).
The pill filter and the search filter stack - pick a status and type some text and you get both filters applied.
7. Read a row in the table
Each row in the table is one API request.
Columns, left to right:
- Method badge: HTTP method (GET, POST, etc.) in colour: GET is blue, POST is green, PATCH/PUT is yellow, DELETE is red.
- Path: the route that was hit, like /vps/01HABC…/power/start.
- Status: the HTTP status code, coloured green (2xx), yellow (4xx), or red (5xx).
- Duration: how long the request took, in milliseconds.
- IP address: the IP the request came from, if the backend was able to capture it.
- Key: the name of the key that authenticated this request (clicking it focuses search on that key).
- Time: when the request happened, shown in your local timezone.
The table is paginated with 50 rows per page. At the bottom, two chevron buttons step you backward and forward in time; between them, a counter shows your page position.
8. Page through older requests
The pagination footer shows:
- Left chevron - previous page (newer rows).
- A page indicator like 2 / 14 between the two arrows.
- Right chevron - next page (older rows).
The page resets to 1 whenever you change a filter or the range pill, so you don't end up on page 12 of an empty filtered list.
9. What to look for
Some realistic things you'd use this tab for:
- Confirm a deployment is using the right key. Filter by key name in the search box and watch traffic come in during the deploy.
- Find a misbehaving integration. Pick the 4xx status pill and look at the path - if one endpoint is failing repeatedly, the integration's making bad requests.
- Investigate a leaked key. Search the key name; if requests are coming from IP addresses you don't recognize, the key may have leaked. Rotate it immediately via Rotating and Revoking an API Key.
- Tune an IP allowlist. Use the IP column to see where each key's legitimate traffic comes from; lock the key to those IPs.
What isn't shown
- Read-only portal traffic - page loads in the dashboard don't go through API keys, they go through your session, so they don't appear here.
- Failed auth attempts where the key was invalid - those don't reach the activity logger (they fail at the auth layer). For those, check the Organization Activity log.