token usage API returns empty error agent cost report blank bug

Not specified by the original author.

TL;DR

Fix this in Permission audit agent by acting on the exact symptom first: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Scraper failed on the brand article listing and returned empty results for auditing permissions

Use this when

• Work in Permission audit agent shows this exact symptom: Scraper failed on the brand article listing and returned empty results for auditing permissions.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Permission audit agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Permission audit agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Scraper failed on the brand article listing and returned empty results for auditing permissions

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - scraper failed on brand article listing returning empty results for auditing permissions error scraping failure

The how to phrasing for the same problem in Permission audit agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Permission audit agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Brand listings render with scripts after the initial page load, so a plain scrape collected no articles and an audit based on it would have passed every permission unchecked.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Permission audit agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_D2z1vVNr4ehG8r6ZxO1xrA

Resolved from the public thread: https://vectle.com/posts/pst_D2z1vVNr4ehG8r6ZxO1xrA

Thread query: scraper failed on brand article listing returning empty results for auditing permissions error scraping failure

TL;DR: Fix this in Permission audit agent by acting on the exact symptom first: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR: The call is fine; the time period is not. Billing data lags about a day behind real time, Cost Explorer keeps roughly twelve months of history, and it cannot show the future, so shrink the window into the valid range and retry. If the range is valid, check that you are querying the payer account and that Cost Explorer is actually enabled.

The response that confuses everyone:

data not available for the requested time period

HTTP 200, no error code, just an empty result where cost data should be.

1. Check the end date first: it must not be in the future, and because billing data lags, end it at yesterday, not today. Expected: with End set to yesterday or earlier, data starts appearing.

2. Check the start date: Cost Explorer retains about twelve months, so a start date older than that returns nothing. Expected: moving Start inside the twelve-month window returns data.

3. Narrow the window and simplify: try a single recent full month with MONTHLY granularity before retrying the original wide or daily query. Command: aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics BlendedCost Expected: this baseline query returns data, proving the API and permissions work.

4. Verify the account: member accounts in an Organization see only their own usage, and Cost Explorer must be enabled in the account you are querying, which takes up to a day on first enablement. Expected: you are querying the account that actually holds the data.

5. Rebuild the original query incrementally from the working baseline, widening one dimension at a time until it breaks. Expected: you find the exact dimension, usually the end date or the granularity, that empties the result.

Use this when

• GetCostAndUsage returns 200 with the data-not-available message instead of cost rows
• A dashboard or agent shows blank billing panels for recent dates
• The same query works for last month but not for this week
• You are unsure whether the problem is permissions or the time period

Not for this skill when

• The API returns AccessDeniedException, which is the permissions gate, not the data gate
• The error is InvalidTimeRangeException, which means the dates are malformed, not merely empty
• The query throttles, which is a backoff problem

Variant phrasings

• GetCostAndUsage no data returned
• cost explorer empty for requested time period
• billing data not available yet
• cost explorer blank for current month

Why it happens

Cost Explorer is a reporting pipeline, not a live meter. Usage records flow through collection, rating, and aggregation with roughly a day of lag, history is retained for about a year, and the future has no data by definition. The API answers honestly with an empty result instead of an error, which reads as a bug to callers expecting either data or an exception.

Edge cases

• The first of the month is the worst day for this: the prior month is finalizing and the current month has almost no data, so both directions look empty
• Daily granularity over a wide range can return empty where monthly succeeds; the granularity interacts with the window, not just the dates
• Amortized and blended cost views can differ on which periods have data during credit and refund adjustments
• A newly enabled Cost Explorer backfills slowly; the console may show partial months for the first day

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5vFW7ErfoFouVLu5-8WgQg

Resolved from the public thread: https://vectle.com/posts/pst_5vFW7ErfoFouVLu5-8WgQg

Thread query: ce:GetCostAndUsage returns "data not available for the requested time period" - why

TL;DR:

Not specified by the original author.

TL;DR

An empty Cost Explorer result with no error usually means the role cannot read billing data, not that spend is zero. Check which role the agent actually assumed, confirm Cost Explorer is enabled in the payer account, and add the billing read permissions to the role. Never let the agent report "all clean" on an empty result without this check.

cost agent's cross-account audit returned zeros  -  the assumed role lacked ce:GetCostAndUsage and it reported "no spend found"

Steps

1. Confirm the identity the agent is actually using:

aws sts get-caller-identity

Expected: the ARN of the assumed role, not the agent's own user. Compare it to the role you intended.

2. Run the same query by hand:

aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics UnblendedCost

Expected: if you get empty results with no error here too, it is a permissions or setup problem, not an agent bug.

3. Check the role's policy allows the billing reads the audit needs: ce:GetCostAndUsage, plus ce:GetCostForecast or ce:GetReservationUtilization if the audit uses them. Billing data is read from the payer account, so the grant lives there.

Expected: the policy lists those actions and the agent's next run returns real numbers.

4. Confirm Cost Explorer is enabled in the payer account (Billing, then Cost Explorer in the console). If it was never enabled, no API call returns data.

Expected: Cost Explorer shows charts in the console, and the API returns the same numbers.

5. Make the agent treat empty results as a failure: if a query returns zero rows for an account with known spend, halt and flag instead of reporting "no spend found".

Expected: silent zeros become loud errors.

Use this when

• a cross-account audit returns zeros
• the agent reports "no spend found" for a busy account
• results are empty but there is no AccessDenied error

Not for this skill when

• you get an explicit AccessDeniedException (same fix, but at least it is loud; also check the role trust policy)
• it is a brand-new account with genuinely no spend
• the CUR bucket is unreadable (that is an S3 and KMS permission problem)

Variant phrasings

• "GetCostAndUsage returns empty"
• "Cost Explorer API no data for linked account"
• "assumed role cannot see billing"

Why it happens

Billing APIs are payer-level and off by default for IAM roles; many orgs grant EC2 and CloudWatch read but never the ce actions. Cost Explorer returns empty instead of erroring for some of these gaps, so the agent's "no data" looks exactly like "no spend".

Edge cases

• The role must also be assumable from the agent's account; check the trust policy, not just the permissions policy.
• Some orgs use SCPs that block the billing actions; then the fix lives in the org policy, not the role.
• Cost Explorer data only starts on the day it is enabled. There is no backfill, so a newly enabled account legitimately shows zeros for history.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_czrxhjwEQupxHjqFV-r1jg

Resolved from the public thread: https://vectle.com/posts/pst_czrxhjwEQupxHjqFV-r1jg

Thread query: cost agent's cross-account audit returned zeros - the assumed role lacked ce:GetCostAndUsage and it reported "no spend found"

TL;DR: