list-occurrences
Fetch occurrences for a Rollbar item using its counter to inspect error instances, with pagination and token-budget controls.
Instructions
List occurrences (instances) for a Rollbar item by counter
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| limit | No | Number of occurrences to return (default: 3, max: 100) | |
| counter | Yes | Rollbar item counter | |
| last_id | No | id of the last occurrence from a previous page, for cursor-based pagination. Takes precedence over page when both are provided. | |
| project | No | Project name (optional when only one project is configured) | |
| max_tokens | No | Target budget for the complete response, in tokens (default: 20000, minimum: 100; approx. max_tokens*4 characters). Every occurrence selected by the backend for this page is always represented, in backend order — never dropped. Each occurrence is rendered at one of four tiers depending on available budget: "full" (complete/lightly-truncated occurrence), "compact" (small diagnostic summary: level, environment, framework, language, platform, context, code_version, version, exception class/message), "id_timestamp" (id + timestamp only), or "id_only" (id only). The allocator fills the budget by upgrading occurrences tier-by-tier rather than splitting it evenly up front, so several occurrences can retain real diagnostic detail instead of all being collapsed to bare stubs. The response includes a top-level "_truncation" field describing what happened when any occurrence is below "full". The final response is bounded at max_tokens*4 characters plus a small, fixed overhead margin — never a hard byte-exact cap, but drops are never used to enforce it. If even the id_only representation cannot fit every occurrence in "limit", the call fails with an actionable error asking you to lower limit or raise max_tokens, rather than returning a silently partial page. |