Skip to content

Usage Accounting Unavailable

URI: https://docs.ankatech.co/errors/usage-accounting-unavailable
HTTP Status: 503 Service Unavailable

When you see this

A request asked a key to apply protection — to encrypt, to sign, or to be the target of a re-encryption or a re-signature — and the use it would count brings the key's usage count exactly to its soft usage limit or to its maximum usage limit. The platform records each such crossing with the use itself, as a signed record written in the same transaction as the count, and that record could not be signed or written. Nothing was counted and nothing was produced: no ciphertext and no signature exists, and the key's usage count is unchanged.

The count and the record of the crossing commit together or not at all, because the crossing is what alerts the key's administrators and, when the key's schedule asks for it, rotates the key. Answering the request without the record would lose the crossing for good.

Only the use that reaches a limit can receive this problem: every other counted use writes no such record.

Response Example

{
  "type": "https://docs.ankatech.co/errors/usage-accounting-unavailable",
  "title": "Usage Accounting Unavailable",
  "status": 503,
  "detail": "The use of the key could not be recorded, so it was not counted and the operation produced no output. The request may be retried.",
  "instance": "/api/v3/crypto/encrypt",
  "correlationId": "2b7e9c41-58d3-4a0f-b6e2-91c4d7a3f058",
  "timestamp": 1790000000
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. The detail names no key, no limit and no cause. The response carries Retry-After: 5.

Where it is answered

Every operation that counts a use of a key: encryption, signature, sign-then-encrypt, the target of a re-encryption or a re-signature, a recipient a multi-key re-encryption keeps, and each signer and recipient of a PKCS#7 conversion, on the buffered, streaming and conversion routes. Decrypting and verifying never count a use and never answer it.

How to Resolve

  1. Retry the same request after the Retry-After delay. The failure is the service's, not the request's, and the use was not counted, so a retry spends exactly one use.
  2. If it persists, the key service cannot write to its database or sign its records: check the service's health (envctl.sh <env> health) and its logs.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.