By Yair Knijn · June 4, 2025

The Savings Plan lapsed on a Friday. The On-Demand bill arrived Monday.

A one-year Compute Savings Plan is a purchase, not a subscription. You commit, book the discount into the forecast, and move on. Nothing auto-renews, nothing pages anyone, and the expiry date lands in a console nobody opens for eleven months. The quiet assumption is that a line item this large will announce its own ending. It won't.

The plan stops on the date written on it, and the next morning every instance hour it had been discounting bills at the full On-Demand rate. Over the weekend the fleet ran exactly as always, every dashboard stayed green, and the only thing that moved was the one number nobody was watching.

Why an expiring commitment never trips an alert

Your alerting is wired to failure: CPU saturates, a queue backs up, a health check flips red. A lapsing Savings Plan produces none of that, because the workload is byte-for-byte identical the second after expiry. Only the rate changed, and rate is not something a monitoring stack watches. So it is the cheapest mistake to prevent and the easiest to miss: no incident, no postmortem, no on-call handoff. The failure mode is silence, and silence is what nobody gets paged for.

The overnight revert to On-Demand

A Compute Savings Plan takes a meaningful share off On-Demand, an EC2 Instance Savings Plan more. When the commitment lapses, the discount does not taper over the following quarter; it is gone at the term boundary. A fleet at high coverage one day pays On-Demand on all of it the next, and the jump is steep enough that finance tends to notice before engineering does.

The detail that catches teams is the asymmetry: the provider gives you a short window to return or exchange a plan after purchase, and no grace at all after expiry. The first real signal is Cost Explorer days into the new month, by which point you have paid On-Demand for every hour since the plan died.

Tracking expirations through the FOCUS dataset

Most teams can't see this coming because commitment data lives in a different shape than usage data, and every provider labels it differently. The FinOps FOCUS specification closes that gap. It defines fields like CommitmentDiscountId and CommitmentDiscountStatus, plus an expiration column, in one vendor-neutral schema, so an AWS Savings Plan, an Azure reservation, and a GCP committed-use discount all surface through the same query. That gives you something to alert on: a scheduled query for every commitment expiring inside the next 60 days, across every account. Write it once against the FOCUS fields and it survives a new account, provider, or term.

Who owns the calendar, and who owns the decision

Tooling surfaces the date. It cannot decide whether to renew, for how long, or at what coverage. Those are judgment calls about where the fleet is heading, and they belong to a named person, not a Slack channel. The moment "the team" owns a renewal, no one does.

• The calendar sits with the FinOps lead: every commitment, its end date, a reminder 60 days out.
• The decision sits with whoever owns that workload's spend, since renewing locks in a baseline for a year.
• The default, when nobody decides, has to be loud. A lapse should cut a ticket, like a missed deploy.

Laddering commitments so nothing lapses at once

If every Savings Plan you hold expires on the same day, you have built a cliff. Ladder them instead: stagger the purchases so a slice rolls off each month, and your exposure at any single renewal stays small. A missed one then costs a rounding error, not the whole baseline, and the monthly cadence forces the calendar to get looked at.

Cloud Horizons treats every commitment as a dated object with an owner and a countdown, normalized through FOCUS so AWS, Azure, and GCP commitments expire on one screen instead of three consoles. The lapse that costs nothing to prevent is the one most worth catching. See how the FinOps view tracks renewals before the bill does.