Expiring coverage

When a Reserved Instance or Savings Plan expires, the usage it was covering falls back to on-demand rates — often silently. CloudQuell surfaces the commitments nearing their end so you can renew before that happens.

Finding what’s expiring

The dashboard doesn’t have a separate “expiring” screen. Instead, the commitments table defaults to sorting by expiry, soonest first, so whatever lapses next sits at the top — and a Status pill on each row marks it Active, Expiring soon (within 60 days), Expired, or Unknown. An “Expiring within 60 days” KPI card gives you the at-a-glance count.

Each row carries the same fields as the rest of the inventory — type, days until expiry, utilization %, dollars saved, and effective cost (the last three over a trailing 30-day window) — so you can prioritize what to renew.

Expired rows don’t linger forever: a lapsed commitment stays in the table for 90 days after its end date as a renew-or-replace prompt, then ages out. If CloudQuell detects you already renewed or repurchased it — a new commitment of the same type and offering on the same billing connection, starting at or shortly before the old one’s end date — the expired row is dropped immediately, so the table only flags lapses that are still unaddressed.

Via the MCP tool

Through the CloudQuell MCP server, the get_expiring_commitments tool returns only the commitments matching a lifecycle status — defaulting to expiring soon, and also accepting expired, active, or unknown. That status filter is an MCP convenience; the dashboard itself shows every commitment in the one sorted table.

Renewal considerations

Before you renew, check the commitment’s recent behavior:

• Utilization — a commitment you’ve been underusing may not be worth renewing at the same size. Right-size or drop it instead of blindly renewing.
• Usage growth — if usage has grown, the replacement may need to be larger. See Savings & recommendations, where CloudQuell suggests purchase recommendations sized to current usage; cross-reference these against what’s expiring.
• Workload changes — if the underlying workload is being retired or re-architected, letting the commitment lapse may be the right call.

CloudQuell surfaces the data to make the decision; it does not renew, purchase, or cancel commitments for you.

Don’t let it slip

To be notified as expiries approach rather than checking manually, set up cost alerts and notification channels. See Alerts overview.

Paid feature

The expiring-coverage detail is available on paid plans; Free plans see a KPI peek. See Plans & billing.

An AI agent connected to the CloudQuell MCP server can pull the same list — “which commitments expire in the next 60 days, and how well are they utilized?” Only AWS is live today; other providers are in development.