Admin console tour

Summary#

The console is one page with a fixed sidebar and 15 screens grouped into Main, Operations and Account. This page walks all 15 in sidebar order, says what each answers, names its data source, and flags the controls only an owner sees. Read it once and you will know which screen to open for any question a customer or an alert raises.

Purpose#

Support and operations questions arrive in three shapes: something is broken, one customer needs something, or a number needs checking. The console is laid out to match. Main is the inbox of things that arrived on their own. Operations is where you act. Account holds the two screens that are about the business rather than the platform. Knowing which group a question belongs to is most of the work of answering it.

Overview#

Chrome that is present on every screen:

• The sidebar carries the METRIC VAULT wordmark, a light and dark theme toggle that persists to localStorage['mv-theme'], a Logged in as: block showing your email, the three nav groups, and a Logout button.
• The maintenance strip sits above all content and renders Maintenance: <message> whenever the maintenance_message configuration key is set. It appears only inside the console. See Runtime configuration.
• Nav badges on Messages, Bug Reports and Workflow Failures show unread or open counts and refresh on their own timers.

The console is English only by design and is excluded from the localization pipeline. It links css/tokens.css and nothing else; the entire component system is inline in the page. It does not load the customer app's css/app.css, and it deliberately does not load the chat widget or the install banners.

Sixteen data sources feed these screens, but only two shapes matter. Most screens POST to a /api/admin/* endpoint with your Supabase token in the JSON body, which reads Cloudflare D1. Four screens talk to Supabase directly from the browser with the anon key: Messages, Bug Reports, the dashboard activity feed and the usage logging helper.

How it works#

Main#

1. Dashboard Overview. The landing screen. Two stat cards, Total Subscribers and New This Month, are computed from the real subscriber list rather than a stored counter. Below them sit a Recent Activity panel, a Quick Actions panel whose single View Analytics button jumps to Usage & Activity, and the Command Center.

The Command Center is the part worth watching. It refreshes on load, on every Dashboard nav click, on Refresh, and on a 45-second interval while the tab is visible. It shows five pulse tiles (Runs (24h), Error rate (24h), Provider cost (24h), Open issues, Paying customers), three charts (Runs & errors / hour, Plan mix, New customers / day) and a merged Recent activity table combining the audit log with the 20 newest error issues, capped at 14 rows. The error-rate tile turns negative at 10 percent or above.

2. Subscribers. The full user directory, built by aggregating usage_counters and user_plans across every month. Search by email or name, filter by plan (All Plans / Starter / Pro / Agency / Enterprise) and status (All Status / Active / Suspended), and export the visible set as subscribers.csv. The per-row View button jumps to the Customers screen with the address pre-filled. There is no pagination: every row renders. Status is real, read from suspended:<email> configuration keys, not inferred.

3. Contact Messages. Everything submitted through the founder-contact widget, read straight from the Supabase contact_messages table, newest first, capped at 200 rows. Four stat cards (Total Messages, Unread, Needs Response, This Week), a filter select (All Messages / Unread Only / Needs Response), search and CSV export. Per message you get Reply (a mailto: link that also marks the message responded), Mark as Read, Mark as Responded and Delete. Deletion is permanent and asks first with the themed confirm Delete this message permanently?.

4. Bug Reports. The same shape over the Supabase bug_reports table: 200 rows, four stat cards, search, a status filter (All / Open / Resolved) and a category filter (All Categories / Bug / Feature / UI / Performance / Other). Each card shows the category pill, the reporter's address or anonymous, the description, the page it was filed from and the first 120 characters of the user agent. Actions are Mark Resolved / Reopen, Reply and Delete.

5. Workflow Failures. The triage queue for failed automated steps. Filter by Open only / All / Resolved only / Timeouts only, with Open only as the default. Four stat cards, a Most Failing Steps card showing up to five step keys with counts, and one card per failure carrying a RESOLVED, TIMEOUT or ERROR pill, the step key and label, the input seed, the error message and a Mark resolved button. The list polls every 25 seconds; new rows pulse the nav badge and slide in up to three toasts that auto-dismiss after 10 seconds and jump to the section when clicked. Resolving a failure is the one mutation here that any admin can perform, and it is the only admin mutation that is not written to the audit log.

Operations#

6. System Health. The analytical view of the same metrics the Command Center summarizes, over a chosen range: Last 24 hours or Last 7 days. Four tiles (Total runs, Error rate, Mean latency, Provider cost), per-provider cards showing spend, calls, errors, latency and token counts where present, and three charts (Runs & errors / hour, Provider cost / hour, Runs by tool).

Below the charts sit two tables you will use often. Tool health rates each tool idle when it had no runs, down at 50 percent errors or above, degraded at 10 percent errors or any timeout, and healthy otherwise. Grouped issues lists deduplicated errors with a Resolve or Reopen button; the issue cell carries the last sample in its tooltip. Last comes Recent admin actions, the audit log, with actor and action filters, a Load more button paging 50 at a time and CSV export. See Error log and resolution and Audit log.

7. Admins. The staff list: email, role, status, who added them, when they were last seen, and per-row actions. Owners also see the Add an admin card. Protected seed accounts render the word protected instead of buttons. Covered in Getting admin access and Managing users.

8. Config. The raw settings store plus three friendly cards over it: Maintenance mode, AI Recommendations access and a Social OAuth readiness table. Everything here is owner-only except reading the table. Full key registry in Runtime configuration.

9. Tools & Cache. Every tool in the catalog with its credit cost, its real cache lifetime, a lifetime override select and a per-tool Clear button, plus an owner bulk row with Apply to all and Clear all cached data. Section tabs filter the table. Covered in Tools and cache management.

10. Customers. The single most used screen in support. Type an address, press Load, and you get the plan, this month's usage against quota, the AI and tool breakdown, an owner-only actions row, the admin actions taken on that customer, a read-only Stripe billing card, connected social channels and team seats. Covered in Customer lookup and billing.

11. Blog Moderation. Customer blog posts across all sites, filterable by title, slug, site, owner email and status (Any status / Published / Draft / Scheduled / Trash), paged 50 at a time. Owners can Unpublish, Trash and Restore. Post content cannot be read or edited from the console: status is the only thing you can change. Covered in Blog administration.

12. Run Log. Per-event history from activity_log. Filter by customer email, free text across tool, title and module, and status (Any status / Success / Failed / Warning / Pending). Paged 50 at a time with CSV export. This is what you read when a customer says a specific run failed. Covered in Run inspection.

13. Job Console. The four background jobs with their real last run, next run, due state and item count, and an owner-only Run due now button. Covered in Background jobs console.

Account#

14. Email Inbox. A Gmail client for the support mailbox, running entirely in your browser and completely independent of the admin sign-in and of the worker. You connect it once with Google OAuth, after which it lists the 25 newest inbox messages with a Load more button, filters them client-side, opens a detail pane that marks the message read, and sends threaded replies. The token lives in localStorage and expires; when it does you get Gmail token expired — please re-connect. and press Connect Gmail again.

15. Usage & Credits. Where credits are going, across all customers. Four stat cards from the same payload the Dashboard uses (Active this month, AI runs (this month), Tool runs (this month), Paying customers), a searchable and plan-filterable table of runs per user per month, and a Top tools by credits — this month bar chart. The table renders at most 200 rows after filtering. Per-event detail lives in the Run Log, not here. Covered in Metrics and usage analytics.