Skip to content

Backend Key Provisioning Unavailable

URI: https://docs.ankatech.co/errors/backend-kek-provisioning-unavailable HTTP Status: 503 Service Unavailable

When you see this

The per-tenant key-encryption-key phase on the deployment key-protection backend got no usable answer in time, or the backend asked the platform to slow down. extensions.reason is UNREACHABLE, TIMED_OUT or THROTTLED. It is raised by the activation (POST /api/v3/admin/platform/setup/backend/activate) after its wrap/unwrap round trip has passed, and — on a deployment with a backend descriptor, when the tenant has no key-encryption key yet — by the eager key step of a tenant create and a key create (POST /api/v3/admin/tenants/{tenantId}/keys). Nothing durable was learned about the configuration or the credential, so this is the one outcome of that phase a retry can clear. The response carries a Retry-After header.

Unlike the round trip's own Backend Self-Test Unavailable, this phase may already have created keys for earlier tenants before it was interrupted. They are kept, named on the failure audit record, and adopted by the next run rather than created a second time. The declared backend is unchanged.

A backend that answered durably — a refused credential or operation, a key that does not exist, a round trip that did not verify — or a protector the platform could not build is not this type: it is Backend Key Provisioning Failed (422, no Retry-After).

Common Causes

  • The backend could not be reached from the platform, or the connection failed in transport (UNREACHABLE): DNS, firewall, security group, private endpoint, appliance link.
  • The backend did not answer inside the time budget (TIMED_OUT).
  • The backend answered with a request-rate limit (THROTTLED): AWS KMS ThrottlingException, Google Cloud KMS RESOURCE_EXHAUSTED, an Azure HTTP 429, or the PKCS#11 adapter's own unwrap limiter.

Response Example

{
  "type": "https://docs.ankatech.co/errors/backend-kek-provisioning-unavailable",
  "title": "Backend Key Provisioning Unavailable",
  "status": 503,
  "detail": "The deployment key-protection backend gave no usable answer in time to the per-tenant key-encryption-key request, or asked this platform to slow down. The capability class in flight was create-key. Nothing durable was learned about the configuration or the credential; retry shortly. Keys created before the interruption are named on the failure audit record. This deployment's declared backend is unchanged.",
  "instance": "/api/v3/admin/platform/setup/backend/activate",
  "timestamp": 1730000000,
  "extensions": {
    "reason": "THROTTLED",
    "requestId": "b41d9a3c-7e21-4f88-9c0d-5a2f7b18e604"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Wait the Retry-After interval and re-run the operation. The activation adopts the keys the interrupted run created rather than creating them again.
  2. If it recurs with UNREACHABLE or TIMED_OUT, check the network path from the platform to the backend and the backend's latency under load.
  3. If it recurs with THROTTLED, check the provider's request quota for the account or project the credential belongs to, and what else shares it. Nothing in the declaration or the credential is wrong.

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