What the admin console cannot do yet
An internal, candid list of the capabilities the admin console does not have, the controls that look functional but are not, and what to do instead in each case.
Last updated 2026-08-06
Summary#
This is an internal page and it is deliberately blunt. It lists the things an admin will go looking for and not find, and the small number of controls that are on screen but cannot do what they appear to do. Everything here has been checked against the code. The point is to save you fifteen minutes of hunting for a button that does not exist, and to stop anyone telling a customer that something happened when it did not.
Overview#
The console is narrow on purpose. Most of what is missing is missing because building it badly would be worse than not having it: a force-logout button that does not revoke a session, or a refund button that does not touch Stripe, is more dangerous than an absence. A few items are genuine defects. Both kinds are below, separated, so you know which to work around and which to fix.
Read this alongside Admin console tour for what the console does have.
Capabilities that do not exist#
| Capability | Status | What to do instead |
|---|---|---|
| Force logout / revoke another user's session | Verified not buildable on the current authentication stack. There is no administrative API to revoke another user's session, and even a sign-out only invalidates refresh tokens: an already-issued access token stays valid until it expires, roughly an hour. No fake button was shipped | Suspend the account. That blocks paid AI runs immediately and is enforced server-side on every request |
| Any Stripe write action (cancel, refund money, change subscription, retry a payment, open the customer portal) | Not built. The billing view is read-only. There is no admin endpoint that mutates Stripe | Do it in the Stripe dashboard. Note the reason in a support record, because a Stripe change made there produces no audit row here |
| MRR or revenue totals | Not built, deliberately. Computing it needs a job that sums every subscription or a per-plan price table, and neither exists in this codebase. Nothing invents a number | Use Stripe's own reporting |
| Customer account deletion | No endpoint and no control | Handle outside the console. There is no supported in-app path |
| Data export for a subject-access or erasure request | No endpoint and no control | Same. Treat as a manual process |
| Impersonation, or "log in as this customer" | No endpoint and no control, at any role | Ask the customer for a screenshot, or reproduce with your own test account |
| Viewing a customer's saved results or report content | Not implemented. The console can see that a run happened, never what it returned | Use the Run Log for the event, and ask the customer for the output. See Run inspection |
| Reading or editing blog post content | Blog Moderation is status-only. The list never fetches a body | Read the post on the public blog. See Blog administration |
| Publishing a blog post from the console | The buttons offered are Unpublish, Trash and Restore. Restore returns a post to draft, and there is no Publish control | Only the customer can re-publish, from Blog Studio. Say so before you unpublish something they want back |
| Sending an email to a customer from the console | Not built. The only outbound paths are mailto: links on Messages and Bug Reports, and the separate Gmail integration on the Email Inbox screen | Use the Email Inbox screen or your normal support channel |
| A friendly on/off switch per tool | Only the raw key and value editor on the Config screen. Tools & Cache has no enable control | Write the tool-off key by hand, and verify the tool id first |
| Pagination on Subscribers | Every row is rendered at once | Filter before the list grows |
| A complete Usage table | At most 200 rows are rendered | Narrow with the email search or the plan filter, or export |
| Rate limiting on admin endpoints | None applied. The only rate limits in the worker are customer quota gates | Nothing to do. Worth knowing during an incident |
| An audit trail for reads | Only mutations are recorded. Nobody can tell who looked at a customer record | Apply the discipline yourself. See Audit log |
| In-flight spinners or disabled states on Refresh and Save | Open work item. Most buttons stay live during their request | Do not double-click. Wait for the message line to change |
Verified defects#
These are on screen and do not behave the way the interface implies. Each has been confirmed in the code.
The Social OAuth readiness card cannot work#
The Social OAuth readiness card on the Config screen calls a diagnostic endpoint without the key that every diagnostic endpoint requires. The request is refused, the refusal parses as valid JSON so no error is thrown, and the card falls through to its empty state.
What you see: the literal text No platforms configured in code. every time, with a blank summary line, regardless of how many platforms are configured.
Impact: misleading readout only. It is not a security hole and it does not affect customers' ability to connect social accounts.
What to do: ignore the card. Do not use it to judge whether social login is configured, and do not report to anyone that no platforms are set up on the strength of it.
The Maintenance card's confirmation appears on the wrong card#
Pressing Save on the Maintenance card writes Saved. to the message line of the Set a config value card above it. The Maintenance card's own message area is never written to.
Impact: cosmetic, but it reads as a failed save. The write did happen. Confirm it in the Configuration table.
Error resolution is under-gated and does not validate its input#
Resolving an error issue is the only mutating admin endpoint gated at admin rather than owner. Its action parameter is also unvalidated: anything that is not the exact string reopen resolves the issue.
Impact: low in practice, since the console only ever sends resolve or reopen. Worth knowing if you are scripting against the endpoint.
Customer mutations report success even when nothing changed#
Every customer action returns success regardless of how many rows it touched. Refunding credits to someone with no usage row this month, removing a seat that does not exist, and resetting usage for an unknown address all report success and write an audit entry.
Impact: real, during support. An audit row proves someone pressed the button, not that anything changed. Always reload the customer record and confirm the numbers moved. See Customer lookup and billing.
Workflow-failure counts describe the page, not the table#
The four tiles on Workflow Failures are computed over the rows returned. The screen requests 300 rows on load, and the 25-second poll requests 50 open rows and overwrites the same tiles. Total Failures can therefore fall shortly after the screen opens.
What to do: press Refresh before quoting any of those numbers.
Two telemetry fields are never populated#
quota_hits is never incremented anywhere. timeouts is only ever incremented against the DataForSEO provider scope, so the Timeouts column in the Tool health table is structurally always zero and the degraded badge can never be triggered by its timeout clause.
What to do: use the Timeouts only filter on Workflow Failures for real per-step timeouts. See Metrics and usage analytics.
Messages and Bug Reports are gated in the browser only#
Those two screens talk to the authentication provider's database directly from the page, and their admin gate is enforced in the page rather than at the data layer. A data-layer hardening task is tracked internally. Deletions there are permanent and are not audited.
What to do: treat those two screens as the least protected part of the console. Do not paste anything sensitive into a contact reply on the assumption that only staff can read the thread.
Password reset always emails one fixed address#
The Forgot password? link on the sign-in screen sends the reset to a single hardcoded address whatever is typed in the field, and the success message names that address.
What to do: reset other admins' passwords from the authentication provider's dashboard. See Getting admin access.
Smaller inconsistencies#
| Item | Behavior |
|---|---|
| Plan badge colors | The free and unlimited plans have no color mapping and render in the same grey as starter |
| Plan filters | The Subscribers plan filter omits free and unlimited. The Usage filter includes them |
| Blog statuses | scheduled can be filtered but cannot be set |
| Confirmation dialogs | Messages and Bug Reports use the themed modal. Cache actions, seat removal and social revoke use the browser's native dialog. Blog moderation has no confirmation at all |
| Status codes | One admin endpoint returns 401 for a missing token where every other returns 403 |
| Error bodies | Admin endpoints return the raw exception message to the client |
| Configuration keys | Any key and any value length is accepted. There is no allow-list, so a typo silently creates a dead key |
| Metrics window | A negative hours value is accepted and returns an empty result set rather than an error |
| Email Inbox | Does not reload when you click its nav item, unlike every other screen |
What to check before reporting something as broken#
- Is it on this page? Most surprises are known.
- Are you an
owner? Almost every missing button is a role difference. See Getting admin access. - Has the settings cache expired? Configuration changes can take up to a minute to reach every running instance.
- Did the action report success without changing anything? Reload the record and confirm the numbers, because success is reported either way.
See also
Was this article helpful?
Thanks — feedback noted for the docs team.