Credit Balances: Track Cloud Credit Grants and Run Out Dates

import { Steps } from ‘@astrojs/starlight/components’;

Credit Balances

Cloud providers hand out credit: promotional credit, startup program grants, an Azure sponsorship or prepayment, a negotiated MACC. It has a start date, an expiry date, and a way of quietly running out days before anyone notices the bill went up. Xplorr tracks each grant against the account it applies to, so you can see the balance, the burn rate and the run out date before either becomes a surprise.

Accessing Credits

Go to Cost Management → Credits in the console. There’s also a Credits card on the dashboard once your organization has at least one active grant, and in Cost Analysis.

Imported automatically

AWS and Azure credits are imported for you; you don’t need to type them in.

• AWS: Xplorr reads your credits with billing:GetCredits every day at 04:05 UTC and when you press Sync now: the amount, what’s left, the expiry date and when AWS expects it to run out. From the payer (management) account it covers the whole organization. Add billing:GetCredits and billing:GetCreditAllocationHistory to the Xplorr policy (see Connect AWS); until then the Credits page shows which accounts are missing it. Only promotional credits are imported, not refunds.
• Azure EA and MCA: credit lots are imported once the billing account (and, for MCA, billing profile) id is set on the account or a grant.
• Google Cloud: Google has no API for credit balances, so Google Cloud credits are entered by hand.

Imported grants show an Auto badge and can’t be edited, apart from the note. If you had already entered the same credit by hand, Xplorr marks the manual one as replaced and leaves it out of totals so nothing is counted twice.

Adding a grant by hand

For Google Cloud credits, or anything the import can’t see:

1. Click New Grant and pick the cloud account the credit applies to.

2. Enter the amount and currency, the start and expiry date, and a source: AWS promotional, AWS Activate, Azure sponsorship, Azure MACC or prepayment, Google Cloud promotional, or other.

3. Add a note if you want a reminder of where the grant came from (a support ticket, a program name, a renewal date to follow up on).

4. For an Azure EA or MCA grant, you can add the billing account (and, for MCA, the billing profile) id. Xplorr then reads the actual remaining balance from Azure directly, instead of only from synced credit lines. See Azure balance API access below.

5. Click Save.

Only admins can create, edit or delete grants.

How burn is calculated

Burn is the credit-category cost lines already synced for that account, inside the grant’s date window and in its currency. Negotiated discounts, bundled discounts and AWS EDP pricing are not counted as burn; only actual applied credit is.

• Remaining balance: the grant amount minus burn so far.
• 30 day burn rate: the trailing 30 days of burn, averaged per day.
• Projected run out date: remaining balance divided by the current burn rate, projected forward.
• Unused at expiry: what the projection leaves on the table if spend continues at the current rate and nothing changes.

If an account has more than one active grant, they draw down in expiry order, the grant expiring soonest first, in both the balance history and the projection.

A credit line synced in a currency that doesn’t match the grant is left out of the total rather than converted or summed; the grant shows Currency mismatch until the currencies line up.

Azure balance API access

An Azure EA or MCA grant with a billing account (or billing profile) id attached reads its real remaining balance from Azure’s Consumption API, refreshed on save, on demand from the grant’s Refresh action, and once a day. The service principal Xplorr already uses for your subscription is scoped to that subscription, which doesn’t reach a billing account by itself; if the read is refused, the grant names the billing role that’s missing, and keeps showing the balance computed from synced credit lines in the meantime. The roles are EnrollmentReader on an Enterprise Agreement, and on a Microsoft Customer Agreement Billing profile reader (plus Billing account reader for MACC commitment lots); see Connect Azure for how to assign them.

AWS and Google Cloud don’t publish a remaining-balance API Xplorr can read, so those stay computed from synced credit lines only.

Google Cloud credit types

Google Cloud reports which kind of credit applied to a cost line: promotional, free tier, or other. A regular grant burns promotional credit only, so it isn’t drawn down by sustained use or committed use discounts. A Free tier grant burns free-tier credit only. If your GCP account synced before this distinction existed, older periods are excluded from burn until a backfill re-reads them; the grant flags this and offers Refresh history to queue it.

Azure pooled credit

An Azure EA or MCA balance covers a whole billing account or billing profile, not one subscription. When more than one grant shares a billing key, only the earliest-expiring live grant reads the pooled balance; the others show Covered by that grant and are left out of the organization total, so pooled credit isn’t counted twice.

Alerts

Credit alerts run once a day, on the same schedule as your other alerts:

• 30 and 7 days before a grant’s projected run out date.
• 30 and 7 days before expiry, only when the projection shows balance will be left unused.

Each threshold fires once per grant, by email to your organization’s admins and as a Slack card in the same layout as your other alerts. Editing a grant’s amount, start date, expiry date, source or currency re-arms its alerts, since any of those can change the projection. If a send fails on one channel, it’s retried automatically without resending the channel that already went through.

What a restricted viewer sees

If your organization restricts which accounts a person can see, a grant that depends on an account they can’t see (directly, or through a shared Azure pool) never shows them a number derived from it: no remaining balance, run out date, unused-at-expiry figure, or burn rate. The console tells them to ask an admin for the balance instead of showing nothing or a wrong figure. Admins always see every figure.

Common mistakes

• Adding a grant after it’s already partly burned. Xplorr only sees synced cost lines from the grant’s start date forward; if the start date is set after credit was already being consumed, the balance will read higher than it actually is.
• Forgetting the billing account id on an Azure grant. Without it, Xplorr computes the balance from synced credit lines, which is accurate but a day or more behind Azure’s own figure.
• Not updating the expiry date after a renewal. A renewed or extended grant needs its expiry date updated, or the alerts (and the “unused at expiry” figure) will fire against the old date.

Related guides

• Notifications: where credit alerts fit alongside budget and anomaly alerts
• Connect AWS, Connect Azure, Connect GCP: the accounts a grant attaches to