Performance & Resilience Settings
What this screen is for
Performance & Resilience is the fifth of the eight purpose groups of Platform Settings, and one of the largest in the whole catalogue. It gathers what the platform does when something is slow, failing or abusive: the circuit breakers and retry policies, the timeout budgets on internal calls, the tiers of the policy cache, and the rate limits. Its address says resilience while the screen reads Performance & Resilience; the slug is kept stable so older links keep working.
The group has four subgroups: Circuit Breakers & Retries, Timeouts, Caching Tiers and Rate Limiting. Every leaf is a plain list of values — no subgroup here administers records of its own — and none of them is a secret, so the Secrets posture filter empties this group entirely.
Only a few of these values can be changed here. Most are owned by the deployment, and the rest are read-only diagnostics; the group card under the Editable filter shows how many you can change. The group's own one-line description invites you to tune these values; for most of them the tuning happens in the deployment environment, not on this screen.
What must exist first
This is a platform screen, reached in the platform context and served only to the platform tenant. Opening it from inside a tenant sends you to that tenant's dashboard, and the request behind it is refused with a bare Forbidden naming neither the tenant nor the permission.
- The permission to read platform configuration. It is what shows Platform Settings in the sidebar and loads the catalogue these counts come from. The platform super administrator, auditor and viewer roles hold it.
- The permission to write platform configuration, for any of the editable values. Only the platform super administrator holds it; a viewer or auditor sees every value and no edit control.
- A third permission for the one value classified dangerous — the streaming read deadline under Timeouts. It is required in addition to the write permission, and the platform refuses the write without it whether or not the screen let you type the confirmation.
- No separate subsystem permission, and no deployment-model gate: all four subgroups are offered on an ANKA-hosted and on a customer-operated install alike.
Decisions you make here
Which values you can actually change
The editable values are unevenly spread, and knowing where they are saves reading many locked rows: most are in Rate Limiting and Caching Tiers, and Timeouts and Circuit Breakers & Retries have one each. Everything else carries a lock.
The lock has two different meanings and the row says which. A read-only diagnostic is an observation the platform reports about itself and there is nothing to set. A deployment-owned value is a real parameter whose owner is the deployment: the row names the deployment setting that holds it, and you change it by editing the deployment environment and redeploying. Both answer 405 Method Not Allowed on a write, so the refusal is the same for an administrator and for a viewer.
Each editable value states in words, beside it, when a save takes effect. Three shapes appear in this group and none of them is a restart:
- Live — applies instantly to all instances. Including every rate-limit switch and the streaming read deadline.
- Reconfigures resilience settings live. The two sign-in request limits and the cache circuit breaker's failure rate.
- Applies to new cache entries (TTL forward). Two values under Caching Tiers. A reduction does not shorten a lifetime already granted.
Because nothing in this group binds at start-up, no change you make here can raise the Restart required banner. If you see it, another group raised it.
How a change is accepted
Opening an editable value gives you a control built from that value's own rules: a boolean offers a switch, a bounded number rejects an out-of-range entry as you type, and the platform is asked to validate your candidate before Save becomes available. If that validation call fails, Save stays disabled — a value is never saved against a verdict nobody gave.
The dangerous value asks you to type its key exactly before Save is enabled, and that typing is a courtesy rather than the control: the permission check runs on the server regardless. If another administrator changed the same value while you had it open, the save is refused and you are told to reload rather than to retry.
One thing to watch when you read a value rather than write it: the source badge shows the raw layer name for four of its five values, and only Not visible from admin-api is written out in words. It means the value is read by some other service and the deployment supplied nothing the settings screen itself can read. Many values in this group can answer that way.
Circuit Breakers & Retries
Exactly one value is editable here: the failure-rate threshold, in percent, at which the cache circuit breaker opens. It defaults to 50, accepts 1 to 100, is classified sensitive, and reconfigures the breaker live.
The asymmetry around it is the thing to understand. The cache breaker's settings have three different owners: its failure rate is editable here, its permitted calls in the half-open state are deployment-owned, and its sliding window and open-state wait are read-only diagnostics. The database breaker is not the mirror image — its failure rate is deployment-owned, so the two breakers are not tuned the same way. Do not infer one from the other.
The rest divides into read-only diagnostics reporting the service-to-service and database breaker and retry settings as the deployment set them, and deployment-owned values: the service-to-service breaker's minimum calls, open-state wait and window duration, the service-to-service retry jitter and maximum backoff, the database and cache retry intervals and multipliers, and the tenant-lifecycle self-heal switch.
That last one is worth naming because it is not really a retry setting. With self-heal off, a service that finds a cached tenant status too old has no way to re-derive it, and the request is denied rather than slowed.
Timeouts
Almost every value here is deployment-owned: the per-operation budgets the platform's services apply when they call one another — sign-in and account operations on one side, key operations on the other, each with a default for everything else — and the read timeout on re-deriving a tenant's status. One value is a read-only diagnostic: the connection timeout of the web server, reported as the deployment set it.
This subgroup's only editable value is the group's only dangerous one: the maximum total time the platform spends consuming the request body of a streaming cryptographic operation. It defaults to 900,000 milliseconds, bounded between 60,000 and 3,600,000, and is evaluated between chunks — so a client trickling bytes is aborted once the budget is spent, but the gap between two consecutive chunks is not bounded. It does not apply to the compact crypto operations. Raising it lets one slow client hold a streaming slot for an hour, which is why it is dangerous.
Caching Tiers
The values governing the policy cache that lets the platform keep deciding while the shared cache or the database is unreachable. Three are editable, two are deployment-owned and two are read-only switches reporting whether the local cache and the periodic refresh sweep are enabled at all.
The three editable values are the ones to weigh together, because each buys availability at the cost of freshness:
- The maximum age of an entry in the in-process policy cache, 24 hours by default, applied forward. Raise it to survive longer cache outages; lower it to pick up policy changes faster. It also gates start-up: with the shared cache down and every on-disk snapshot older than this, the cryptographic service finds no valid policy and refuses to start.
- The lifetime of the shared policy cache entries, 168 hours by default, also applied forward. A long lifetime means a revoked or retightened policy keeps being served from cache for hours; a very short one pushes every policy decision back to the shared cache.
- The retention of the persisted on-disk policy snapshot, 7 days by default, live on save. It governs the last resort when both the shared cache and the database are unreachable, so shortening it narrows the outage the deployment can ride out before cryptographic operations start being denied.
The two deployment-owned values are the policy-refresh schedule values. How long a tenant suspended or revoked in the control plane can keep operating on a cached status is not a setting: the platform re-checks a cached tenant status that is more than ten minutes old, a bound fixed by the platform.
Rate Limiting
Most values here are editable, and all of those are classified sensitive or above. Four govern the application-layer sign-in limiter: its master switch, the per-minute login-attempt budget, the general per-minute request budget, and the cooldown applied once a limit is tripped.
Three cautions the entries themselves state. Switching the limiter off disables the per-account login bucket and the per-address request bucket at once, leaving only the edge limits, which know nothing about accounts and cannot slow a credential-stuffing run spread across addresses. The request bucket is keyed on the caller address, so whole offices and mobile networks arrive behind one address and a value tuned for one user throttles all of them. A cooldown above zero makes a rejected request hold a server thread for that long, amplifying a flood rather than protecting against it.
One editable value sits here although it is not a rate at all: the maximum plaintext size the compact crypto operations accept, four million bytes by default. It bounds how much of a request body every compact encrypt, sign and sign-encrypt buffers, and the envelope ceiling for the inverse operations is derived from it — so lowering it also narrows what can be decrypted or verified.
The edge limits are read-only for a structural reason: the edge configuration is not rendered from the settings plane, so these rows report what was deployed and cannot change it.
How it relates to other screens
The group root explains the vocabulary this page assumes — posture, source, assignment, the propagation types and the restart banner — and is worth reading once:
The infrastructure these budgets are spent on, and the live view of whether it is answering, are elsewhere:
What the policy cache on this screen holds is decided on the policy screens, not here: