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

Under normal conditions, changes propagate across the platform in under 1 second, and in almost all cases within a few seconds. There is no hard upper bound: during bulk changes or while the service is recovering (see below), propagation can take longer than 30 seconds.

This applies equally to granting and revoking access, including deny rules. A revoked permission can remain effective for the same window.

Why isn't it instant

Every gatekeeper instance keeps the permission rules in memory so permission checks stay fast. When you make a change:

1. It's immediately saved to the permissions database and applied on the instance that handled the request.

2. The change is broadcast to all other gatekeeper instances, which apply it within a fraction of a second.

3. Small internal caches (group membership, UI permission flags) are cleared when a relevant change arrives. As a safety net they also expire after at most 30 seconds.

If an instance can't apply a broadcast change directly (for example during bulk updates, or when a batch contains conflicting changes), it falls back to a full reload of all rules from the database. A full reload starts after a short quiet period of about 5 seconds and takes additional time depending on the number of rules. To protect the service from running out of memory, back-to-back reloads are spaced at least 30 seconds apart. This is why propagation can exceed 30 seconds under heavy change volume. Permission checks keep working during a reload, using the previous complete set of rules.

What admins should know

• Wait a few seconds after making a change before asking a user to retest access. After a bulk change (many users, groups, or roles at once), allow a minute or more.

• Revocations are not instant either. If access must be cut off immediately (e.g. a security incident), contact the Platform team so they can force a refresh across all instances.

• Changes are always saved. A permission change is persisted to the database before it is broadcast, so it is never lost from the source of truth. However, if the broadcast doesn't reach an instance, that instance keeps the old state until its next full reload or restart. There is no periodic automatic refresh.

• Changes are company-scoped. Updates to one company's permissions don't affect others.

• If a user still sees the old behavior after a minute, something may be wrong — contact the Platform team.

Degraded scenarios

Very rarely, internal infrastructure can be degraded (e.g. the message broker is down or an instance temporarily loses its connection). In those cases:

• Existing permission checks continue to work using the last-known state.

• New changes are saved to the database but may not reach other instances. Those instances stay on the old state until a full reload is triggered or the instance restarts.

• The Platform team can force a full refresh across all instances. Gatekeeper alerting currently covers slow permission checks, crash loops and unusual deny rates; broadcast failures are not guaranteed to raise an alert, so report suspected stale permissions to the Platform team.

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 (the list of enforced companies)

• Switching between enforce / report-only / disabled modes

These require coordination with the Platform team to roll out a restart.