Skip to main content
The Cache Explorer is an internal administration view that shows what the application server is currently holding in its in-memory cache, and lets you drop entries when a stale value needs to be refreshed immediately.
It is reachable by URL only — /cache/explorer — and is not linked from the application menu. It is an operational tool, not part of the end-user navigation.

​
Who can use it

Only users that are admin or hold a role with access to the FeatureDesigner feature. Both the view and the underlying endpoints enforce this: a user without those permissions is redirected to the home page and the API rejects the request.

​
What you see

The explorer lists one row per cached key: Above the table, two counters show how many keys are cached and how much memory they use against the limit of the application plan.
The cached values are never shown. Cache entries hold application data (user profiles, feature payloads, query results) that could be sensitive, so the endpoint only exposes keys and metadata.
Some keys carry the identity of a user in their own name — the email of the session they belong to, a user id, or the text somebody typed into the AI agent. Those keys are shown redacted: the prefix stays readable and the identifying part becomes a short digest, e.g. USER_VALIDATION-<redacted:9f2c1a04b7de>. You can still search and delete them by that redacted name.

​
What you can do

  • Search — filter the list by any part of the key. The search is a plain, case-insensitive substring match.
  • Delete one entry — removes a single key. The next request for that data reads from the source again.
  • Clear the whole cache — flushes the cached data of the instance. Safe but not free: the following requests re-read everything from MongoDB / SQL Server, so expect a temporary slowdown.
Clearing does not drop the authentication entries. Rebuilding those means one Auth0 profile call per active user, so they are deliberately kept: a repeated flush would otherwise exhaust the Auth0 quota and lock everyone out of the application. Signed-in users stay signed in.
The cache lives in the memory of each application instance. Clearing it affects the instance serving your request; if your application runs on several instances, each one keeps its own cache.