Administration
The internal staff console at /admin.html, who can reach it, what each screen does, and where every operational task is documented.
Last updated 2026-08-06
Summary#
The admin console is a single self-contained page, admin.html, served from the same Cloudflare Pages project as the customer app. It is where staff look up a customer, change a plan, suspend an account, read the error log, tune cache lifetimes, trigger a background job and audit what other admins did. This category documents it screen by screen, endpoint by endpoint, with the exact strings and the exact numbers the code uses.
This category is internal. Nothing here is written for a customer to read.
Overview#
Three things are worth knowing before you open any other page in this category.
The page itself is not gated. admin.html is a plain static asset. The worker has no route for /admin or /admin.html, so anyone can load the HTML. What is gated is every /api/admin/* call the page makes: each one carries a Supabase access token in its JSON body and the worker resolves that token to an admin identity before answering. An unauthorised visitor sees a login screen and gets nothing but 403 responses. See Getting admin access.
There are exactly two roles: owner and admin. Every screen is visible to both. Every mutation except resolving an error issue and resolving a workflow failure is owner-only, enforced server side and mirrored in the UI by hiding the owner-only cards. The full matrix lives in Getting admin access.
Every mutation is written to an audit log. admin_audit_log records the actor, the action, the target and a short meta string for all 17 mutating actions. It is readable from System Health and, filtered to one customer, from the Customers screen. See Audit log.
Get in#
- Getting admin access — the full authentication chain, the
admin_userstable, theADMIN_EMAILSseed floor, and the seed-owner and self-action guards. - Admin console tour — all 15 screens, what each is for, and where its data comes from.
Day-to-day operations#
- Managing users — the subscriber directory and every admin-account mutation.
- Customer lookup and billing — look up one customer, read their plan and usage, and set a plan, reset usage, refund credits, suspend, reactivate or remove a seat.
- Run inspection — the per-run activity log, filtered by customer, tool or status.
- Error log and resolution — grouped error issues, resolving and reopening them.
- Metrics and usage analytics — hourly run, error, latency and provider-cost metrics.
- Background jobs console — the four background jobs, their real state, and running one now.
- Blog administration — moderating customer blog posts.
- Maintenance and health — the maintenance banner and system health checks.
Configuration#
- Runtime configuration — every runtime configuration key, its default, its effect and its risk.
- Tools and cache management — per-tool cache lifetimes, the global default, the apply-to-all control and cache clearing.
Reference#
- Audit log — the complete audit action vocabulary.
- Data browser — reading the underlying tables.
- What the admin console cannot do yet — what the console deliberately cannot do yet, and why.
See also
Was this article helpful?
Thanks — feedback noted for the docs team.