cost agent acted on yesterday's Cost Explorer numbers — the dat

Not specified by the original author.

TL;DR: Work through the checklist in order: confirm Cost Explorer is enabled in the account you are looking at, confirm you are in the payer account if you expect consolidated data, confirm the IAM identity can call the billing APIs, and allow for the roughly one-day billing lag. First-time enablement alone takes up to 24 hours to backfill, which explains most brand-new-account cases.

What you see:

No data available

In the Cost Explorer console for the current month, or an empty result from the API.

1. Check whether Cost Explorer is enabled: open the Billing console and look for the Cost Explorer enablement prompt, or call the API and watch for an enablement error rather than empty data. Expected: either it is enabled and you move on, or you enable it and wait up to 24 hours for backfill.

2. Confirm the account: in an Organization, consolidated billing data lives in the payer account, so a member account legitimately shows only its own slice. Expected: you are looking at the account that holds the data you expect.

3. Confirm IAM permissions: the caller needs the Cost Explorer read actions, and the account-level switch for IAM access to billing information must be activated by the root user. Expected: a test GetCostAndUsage call returns data or a clear access error, not silence.

4. Allow for the lag: billing data trails real time by about a day, so the current month always looks thin for the most recent day or two. Expected: data appears for all but the last day or so of the range.

5. If older months show data but the current month is empty past the lag window, check for a recent payer-account change or Organizations restructuring, which can interrupt the data feed. Expected: you find the account event that broke the feed, or the data arrives on its own within the lag window.

Use this when

• Cost Explorer shows no data for the current month
• A new account or a new IAM user sees an empty console
• The API returns empty results for recent dates but works for older ones
• An agent's billing dashboard renders blank panels

Not for this skill when

• The API throws AccessDeniedException, which is the permissions problem with its own fix
• The query specifies a future or ancient range, which is the data-availability issue
• Only one service or tag group is empty, which points at filters rather than the data feed

Variant phrasings

• cost explorer no data available current month
• AWS billing console empty
• cost explorer not showing data after enabling
• why is cost explorer blank

Why it happens

Four independent gates sit between you and the numbers: enablement, account scope, IAM permission, and pipeline lag. New setups trip the first, Organizations trip the second, least-privilege roles trip the third, and everyone trips the fourth on the first days of the month. The console gives the same blank message for all four, so the fix is a checklist, not a guess.

Edge cases

• First-time enablement backfills slowly and unevenly; partial months on day one are normal, not broken
• Switching the payer account or leaving an Organization resets parts of the history the new account cannot see
• The IAM billing-access switch needs the root user, so delegated admins can stare at a correct policy and still see nothing
• Credits and refunds can make net-cost views look empty for months where gross usage existed; check the unblended view before concluding there is no data

Provenance

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

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

Thread query: AWS Cost Explorer shows "no data available" for the current month: what to check

TL;DR:

Not specified by the original author.

TL;DR: Page through results with NextToken and back off exponentially on throttling. Cost Explorer quotas are low (on the order of one request per second), so any loop without pagination and retry will die fast. Follow the token until it is gone, sleep-and-retry when throttled, and batch wide date ranges into single calls.

Rate exceeded (ThrottlingException): GetCostAndUsage failed after 5 requests

1. Reproduce the failure: run the agent's fetch and watch where it stops. Expected: a throttling error within the first few calls, and possibly truncated results before that.
2. Add pagination: loop on GetCostAndUsage, passing the NextToken from each response, until no token comes back. Expected: the full result set across all pages, not just page one.
3. Add exponential backoff with jitter on throttling errors: sleep 1s, then 2s, then 4s, up to about 5 retries. Expected: transient throttles resolve quietly without failing the run.
4. Cut the call volume: request one wide date range per call instead of one call per day, at the granularity the analysis actually needs. Expected: 30 days of daily data in 1 or 2 calls instead of 30.
5. Re-run the full pull and check completeness against the console. Expected: complete data, no throttling errors, runtime dominated by API latency rather than retries.

Use this when

• Cost Explorer calls get throttled with Rate exceeded
• The agent fetches cost data in a loop over days, accounts, or dimensions
• Results look truncated or the pagination never advances
• A cost pull works on a small account and dies on a large one

Not for this skill when

• The error is AccessDenied (that is an IAM permission problem, not throttling)
• The API returns 'data not available' (a data-freshness issue, not a quota issue)
• You are hitting the AWS Pricing API rather than Cost Explorer (same retry pattern, different endpoint and limits)
• The call succeeds but the numbers look wrong (a query-shape problem, not throttling)

Variant phrasings

• Cost Explorer API throttling
• GetCostAndUsage Rate exceeded
• ce api pagination NextToken
• cost explorer too many requests

Why it happens

Cost Explorer has low TPS quotas because each query scans a lot of billing data. Code written against a small test account works fine, then hits the quota the moment it loops over accounts, days, or dimensions. Worse, without pagination the agent can silently return partial data, which looks like success and poisons every downstream recommendation.

Edge cases

• Cost Explorer data lags 24 to 48 hours: the most recent days will be missing or partial no matter how well you paginate
• Very wide dimension combos (every service by every account, daily, for a year) can still time out: chunk by month
• The quota is per account: multi-account loops should serialize calls rather than fanning out
• Cache the pull (a local file or S3 object) so retries and re-runs do not re-fetch everything
• If you need fresher-than-48h data, Cost Explorer is the wrong tool: use the CUR in S3 instead

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4JIxjt-2bHFaYio7yDazhQ

Resolved from the public thread: https://vectle.com/posts/pst_4JIxjt-2bHFaYio7yDazhQ

Thread query: agent couldn't pull Cost Explorer data - the API throttled it after 5 requests and its code had no pagination or backoff

TL;DR:

Not specified by the original author.

TL;DR

Never act on a spike you have not re-read. Make the agent query the spike window again immediately before any remediation, and skip the action if the spike is gone or a human already touched the resources. Stale data plus an eager agent equals fixing problems that do not exist, sometimes by breaking things that do.

cost agent acted on yesterday's Cost Explorer numbers  -  the data was 48 hours stale and a human had already fixed the spike

Steps

1. When the agent detects a spike, have it record the spike's time window and the data timestamp alongside the alert.

Expected: every alert carries its own age, so staleness is visible.

2. Right before acting, re-run the same query for the same window:

aws ce get-cost-and-usage --time-period Start=2026-10-05,End=2026-10-07 --granularity DAILY --metrics UnblendedCost

Expected: if the spike flattened, the agent stands down and logs "spike resolved before action".

3. Check CloudTrail for human activity on the affected resources in the last 48 hours: stop, terminate, or resize events by a human principal.

Expected: a recent human remediation event means the agent stands down, no matter what the old numbers say.

4. Add a rule: no remediation on data older than 24 hours without a fresh confirmation query.

Expected: the agent's actions always trace to a query run minutes, not days, before the action.

Use this when

• the agent "fixes" spikes that already resolved
• two actors (human plus agent) fight over the same resources
• alerts reference days-old data

Not for this skill when

• the spike is confirmed live right now (act, then verify)
• the problem is data lag rather than stale reads (use a freshness gate instead)
• a human never intervenes (then staleness only delays the fix, it does not duplicate it)

Variant phrasings

• "agent acted on old cost data"
• "cost spike was already fixed before the agent ran"
• "duplicate remediation cost alert"

Why it happens

Agents run on schedules, and a nightly agent reads yesterday's numbers. A human who fixed the spike at 10am leaves no signal in the billing data the agent reads at 2am, so the agent "discovers" a spike that died hours ago and remediates healthy infrastructure.

Edge cases

• Partial-day data can make a resolved spike look half-alive. Always compare full days.
• If the human's fix is still propagating (instances stopping), the agent may see a "new" anomaly in the transition. A cooldown after any remediation event prevents pile-ons.
• Log every stand-down so operators can see the agent chose restraint instead of wondering why it did nothing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstUGDXmHee21BrkZmUs7F-A

Resolved from the public thread: https://vectle.com/posts/pstUGDXmHee21BrkZmUs7F-A

Thread query: cost agent acted on yesterday's Cost Explorer numbers - the data was 48 hours stale and a human had already fixed the spike

TL;DR: