{"version":"2.1.318","anchor":"usage-report-504-message-now-points-at-actor-ids-instead-o","canonical_anchor":"usage-report-504-message-now-points-at-actor-ids-instead-o","heading":"Usage report timeout advice now suggests filtering by actor IDs","tier":"notice","area":"Elsewhere","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318\/e\/usage-report-504-message-now-points-at-actor-ids-instead-o","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318","markdown":"### Usage report timeout advice now suggests filtering by actor IDs\n\nWhen a usage report times out, the error now suggests narrowing it with `actor_ids[]` (up to 100 a call) instead of `rbac_group_ids[]`\n\n**Unclear.** It is not clear whether `rbac_group_ids[]` is still accepted as a filter.\n\n**What**\n\nWhen a usage report request takes too long and fails with a timeout, the error message suggests ways to make it smaller. It now suggests asking for only some `actor_ids[]`, up to 100 a call, or leaving out `time_bucket_width`. Before, it suggested asking for only some `rbac_group_ids[]`.\n\n**Why**\n\nThe advice suggests the report now filters by actor (the person or key that did the work) rather than by permission group, so that is the filter to reach for when a report is too big.\n\n- Area: Elsewhere\n- Names: `time_bucket_width`\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: org\n- Heads-up: no"}