Cache Permission SLA
2 min read
How long do permission changes take to apply
When an admin makes a permission change, adding or removing access, assigning a role, updating group membership, there's a brief delay before the change takes full effect across the platform. This page explains what to expect.
Expected timing
Change type | How fast it applies |
|---|---|
Permission change for a user or group | Up to 30 seconds |
Access granted or revoked on a resource | Up to 30 seconds |
Group membership added or removed | Up to 30 seconds |
Changing the gatekeeper running mode (enforce / report / disabled) | Requires a service restart |
Under normal conditions, most changes propagate across the platform in under 1 second. The 30-second figure is the worst-case guarantee.
Why isn't it instant
The platform uses short-lived internal caches to keep permission checks fast (sub-millisecond). When you make a change:
It's immediately saved to the permissions database.
The change is broadcast to all running services so they can refresh their view.
A small membership cache refreshes within 30 seconds at the latest.
This design means the platform handles millions of permission checks per second without overloading the database, at the cost of a short propagation window.
What admins should know
Wait ~30 seconds after making a change before asking a user to retest access. If they still see the old behavior after that, something may be wrong — contact the Platform team.
Permission changes are never lost. Even if the broadcast fails, the next automatic refresh will pick up the change.
Changes are company-scoped. Updates to one company's permissions don't affect others.
Degraded scenarios
Very rarely, internal infrastructure can be degraded (e.g. the message broker is down). In those cases:
Existing permission checks continue to work correctly using the last-known state.
New changes may take longer than 30 seconds to propagate.
The Platform team is alerted automatically and can force a refresh if needed.
Changes that require a restart
A few settings are read once when a service starts and cannot be updated on the fly:
Enabling or disabling gatekeeper for a company
Switching between enforce / report-only / disabled modes
These require coordination with the Platform team to roll out a restart.