---
title: "2026-07-24 · Overage is now recorded, not silently allowed"
description: "Under the allow and notify policies, a consume over balance used to succeed with nothing recorded. It now floors the balance at zero and records the shortfall as an overage event."
order: 9
date: "2026-07-24"
---

# Overage is now recorded, not silently allowed

Under the `allow` and `notify` [overage](/docs/concepts/overage) policies, a consume that cost more than the balance held used to succeed quietly. Nothing was debited, and nothing was recorded.

## Changed — overage is drained and written down

A consume over balance now drains whatever spendable credit exists, floors the balance at zero, and records the shortfall as an overage event. The stored balance never goes negative.

`reason: overage_recorded` replaces the old `overage_allowed`. The request still succeeds — `allowed` stays `true`. This is informational, not an error.

```json
{
  "allowed": true,
  "debited": true,
  "overage": 2000,
  "reason": "overage_recorded"
}
```

## Added — `overage` on the consume response

Millicredits, like every other amount. Present only when overage was accrued on that call.

## Added — `total_overage` and `overage_by_billable_metric` on `subscription.renewed`

Both land inside `usage_summary`, for postpaid renewals. Both are `0` or empty when no overage accrued during the period.

## Where to read overage later

A window query landed the next day: `GET /v1/customers/{customer_id}/overage`, covered in the [2026-07-25 entry](/docs/changelog/2026-07-25). See [Billing Overage in Arrears](/docs/cookbook/overage-billing-in-arrears) for the full reconciliation recipe.