Skip to content

Every /admin screen

This is the long-form walkthrough of every screen a platform admin will touch. The shorter pages under Operations → Platform Admin are quick reference cards; this is the tutorial. Read it once in order; afterwards use the anchor links to jump to the screen you need.

The screens are grouped two ways:

  • The main /admin tabbed dashboard (eleven tabs)
  • The side surfaces (seven dedicated URLs that live at /admin/...)

Each section follows the same shape: URL, purpose, controls visible, common tasks, what to watch for, and a link to the matching reference page.

The main /admin dashboard

/admin is a single page with eleven tabs across the top. The tab is encoded in the ?tab=... query parameter so URLs are linkable and bookmarkable.

Feature Flags

URL: /admin?tab=features (this is the default landing tab) Reference: operations/platform-admin/features.md

This tab is the master kill-switch panel for product features. Above the flag list, the Frameworks section lets you choose the default new-project framework (covered next, also reached via this tab).

Controls visible

For every registered feature flag, you get a row with:

  • Master toggle at the left: flips enabled true/false (PATCH to the API). Off means the feature is invisible everywhere immediately.
  • Label and small mono feature_key code-pill so you can grep logs.
  • Description: one-liner explaining what the flag controls.
  • Right-side pills: Pro+ / Business+ shows the minimum plan; Admin+ / Owner+ shows the minimum workspace role.
  • Expand chevron: reveals two selects: Min Plan (None / Free / Pro / Business / Enterprise) and Min Role (None / Member / Admin / Owner).

Resolution at runtime: server-side featureFlagQueries(sql) looks up the row; the client useFeatureFlag(key) returns its current state. Most flags resolve in a single Postgres lookup.

Common tasks

  • Toggle "Marketplace publishing" off platform-wide during an outage
  • Restrict "Provider Bridge BYOK" to Pro+ workspaces
  • Limit "Custom domains" to workspace owners only
  • Walk the full list on a fresh install to make sure nothing is silently enabled

Watch for: the UI does not yet support adding or deleting flags. A new flag means a backend migration. Disabling a flag does not delete the data the feature wrote; turn it back on and the data is still there.

Frameworks

URL: /admin?tab=features (rendered above the flag list) Reference: operations/platform-admin/frameworks.md

The Frameworks section manages the project-scaffold catalogue that powers the "Create Project" dialog.

Controls visible

  • Per-framework row with icon (Atom for vite-react, Globe fallback), name, category, "Default" pill when applicable
  • Set as default link on enabled non-default rows
  • Enable / disable toggle
  • Save → PUT /admin/frameworks with { enabledFrameworks: string[], defaultFramework: string }

Common tasks

  • Enable Next.js App Router projects platform-wide
  • Switch the default from vite-react to nextjs-app
  • Disable a deprecated framework

Watch for: the UI will refuse to let you disable every framework. At least one must remain enabled. The default can only be set on an enabled framework. Disabling a framework hides it from the picker but does not break existing projects of that type.

DNS

URL: /admin?tab=dns Reference: the first-time-setup DNS section; no separate ops stub yet

This tab is the Cloudflare wildcard automation panel. It uses KEK-encrypted CF API tokens stored in platform_settings.

Controls visible

  • Mode toggle: per_publish vs wildcard. The defaulted flag indicates whether the active mode is inferred or admin-set.
  • Diagnostics card: zone name, plan, ACM status (hasAcm boolean plus enabled / absent / undetectable), publish domain, recommended wildcard hostname, configured wildcard, existing wildcard record, full allWildcards list, canAutoSetup boolean plus a reason enum (ok, no-cf-creds, no-tunnel-id, no-publish-domain, free-plan-multilevel, zone-lookup-failed), and a human message.
  • Custom wildcard input: must start with *., lowercase a-z 0-9 dot hyphen, must be inside the zone. Optional Apply ACM override checkbox for paid ACM zones with multi-level wildcards.
  • Auto Setup button → POST /admin/dns-mode/auto-wildcard, returns { wildcardHostname, target, created, updated, acmOverrideApplied, diagnostics }.
  • Existing wildcards list: per-row hostname, target, proxied, modifiedOn. Trash button uses a two-step confirm (confirmingDelete → deleting).
  • Cloudflare API token override: collapsible section showing source (platform_settings / env / none), token suffix, hasSslScope, decryptFailed. Auto-expands when stored ciphertext can't be decrypted (KEK rotation). Paste a new token to write; trash button to delete.

Common tasks

  • Confirm wildcard is healthy on a fresh server
  • Rotate the Cloudflare API token (KEK-encrypted)
  • Delete a stale wildcard CNAME left over from an earlier environment
  • Force ACM override when running a paid zone with multi-level wildcards

Watch for: free Universal SSL only covers <zone> and *.<zone>. Multi-level wildcards like *.staging.doable.me need paid ACM. The dash-not-dot rule (staging-api.doable.me, not api.staging.doable.me) is enforced server-side in deployment/server-setup.sh. Do not flip it manually.

Signups

URL: /admin?tab=signups Reference: operations/platform-admin/signups.md

This tab gates new registrations. If you do not approve signups manually, the only useful piece here is the blocked-email list.

Controls visible

Three cards, top to bottom.

Settings card - Checkbox: "Require approval for new signups" (writes enabled) - Textarea: "Message shown to pending signups" (max 2000 chars; writes pending_message) - "Discard changes" link appears when dirty - Save settings → PUT /admin/signups/config

Pending approvals card - Count badge next to "Pending approvals" - Refresh link - Per-row: display name, email, provider badge (Email / GitHub / Google), signup time - Per-row buttons: Approve (green) · Deny · Block (red) - Approve → POST /admin/signups/:userId/approve (server-side ensureWorkspace creates the user's personal workspace) - Deny → POST /admin/signups/:userId/deny - Block → POST /admin/signups/:userId/block (denies and adds the email to blocked_signups so they cannot return via GitHub or Google either)

Recently denied card (shown only when non-empty) - Last 20 denied users with Approve to reverse

Blocked email addresses card - Lists rows from signupApproval.listBlocked() - Unblock trash button → DELETE /admin/signups/blocked/:email

Common tasks

  • Turn signup approval on/off and customise the pending-screen message
  • Approve a queued waitlist user
  • Block a spam email permanently
  • Unblock a previously-blocked email if you over-rotated

Watch for: Block is stronger than Deny. A denied user can sign up again; a blocked email cannot, even via a different OAuth provider. Use Deny by default and reach for Block only when you have evidence of abuse.

Users & AI

URL: /admin?tab=users Reference: operations/platform-admin/users.md

The user management surface: the single most-used tab on the panel.

Controls visible (toolbar)

  • Search field: filters by email or display name (search query param on GET /admin/users)
  • Role filter dropdown
  • Plan filter dropdown
  • Bulk select checkbox column plus a bulk-apply popover (model, addQuota, role, plan)
  • Add user button: opens the invite flow

Controls visible (per row)

  • Avatar bubble (initial of display name / email)
  • Display name + email; the Crown icon marks is_platform_admin
  • Role select: WORKSPACE_ROLES (owner, admin, member, …); writes PATCH /admin/users/:userId/role
  • Plan select: WORKSPACE_PLANS (free, pro, team, enterprise); writes PATCH /admin/users/:userId/plan
  • Source badge: Copilot, Custom provider, or "WS default · …"
  • Effective model badge: colour-coded by resolution source: enforced (red) → user (emerald) → workspace (blue) → none (grey)
  • Credit mini bar: daily remaining / daily total; green ≥50%, amber ≥20%, red below
  • Row click opens UserDetailModal

UserDetailModal

Two tabs.

  1. AI Model & Source: source toggle (Copilot / Custom), Copilot account select, Copilot model select (dynamic via useCopilotModels), Provider select, Provider model select (dynamic via useProviderModels, falls back to FALLBACK_MODELS). Save writes PUT /admin/users/:userId/ai-allocation. Reset to defaults does DELETE on the same endpoint.
  2. Credits: three numeric fields (daily, monthly, rollover) with server caps CREDIT_CAPS = { daily: 100_000, monthly: 1_000_000, rollover: 1_000_000 }. Save and Save & Reset Usage buttons. Writes PATCH /admin/users/:userId/credits.

Common tasks

  • Find a user and switch their plan to Pro
  • Allocate a Copilot account plus model to a power user (the source account is cloned into their owned workspace with re-encrypted token via cloneCopilotAccountToWorkspace())
  • Give a user 5 000 extra rollover credits for the month
  • Bulk-set 30 users to model gpt-4o-mini and role member
  • Promote a user to platform admin so you have a backup

Watch for:

  • Self-protection: the API refuses to demote your own is_platform_admin or platform_role. The UI mirrors this, so you cannot accidentally lock yourself out.
  • Personal-scope provider rows are invisible to admins. You will only see workspace-scope rows in the source/model dropdowns.
  • The list returns a flat snake_case array (GET /admin/users). Do not wrap it. BUG-ADMIN-012 is the recorded reason at line 58 of admin-users.ts.

Integrations

URL: /admin?tab=integrations Reference: operations/integrations-admin.md

This is where the platform pre-provisions OAuth apps so end users do not need to register their own. Phase 1 + 2A/2B is deployed; phases 2C/2D are deferred.

Controls visible

Integration list with search. Per integration:

  • Source badge: Platform app, Workspace app, Env-configured, or Personal
  • Client ID display (truncated suffix or full)
  • Add OAuth credentials form (clientId, clientSecret, optional extraConfig JSON, isGlobal toggle)
  • Edit / Rotate / Delete actions
  • Connect Test button: runs the OAuth handshake via the enhanced-auth route

Backend behaviour:

  • GET /integrations/admin/oauth-apps?workspaceId=… returns the rows
  • POST /integrations/admin/oauth-apps creates new entries; the isGlobal: true flag requires platform admin and makes the app available to all workspaces
  • clientSecret is encrypted at rest and never echoed back
  • Google integrations share GOOGLE_INTEGRATIONS_CLIENT_ID / GOOGLE_INTEGRATIONS_CLIENT_SECRET (with GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET as fallback)
  • GitHub integrations share GITHUB_CLIENT_ID / GITHUB_CLIENT_SECRET
  • Env-configured apps cannot be deleted from the UI; change them in .env and restart

Common tasks

  • Register a global Slack OAuth app so every workspace can connect
  • Rotate Google client secret across all workspaces (delete + re-add)
  • Restrict GitHub OAuth to per-workspace apps only (delete the global entry)
  • Audit which integrations are env-backed vs DB-backed
  • Verify a freshly-added OAuth app with Connect Test

Watch for: TBD in the research: the exact UI control for forcing personal-only on a per-integration basis is not yet documented. Treat platform vs personal as advisory until that surface ships.

Plans

URL: /admin?tab=plans Reference: operations/platform-admin/plan-limits.md

Two sub-tabs in one card: Limits and Defaults.

Sub-tab: Plan Limits

Plans listed in PLAN_ORDER: Free, Pro, Business, Enterprise. (Note: not "Team".)

Per plan, an expandable card shows:

  • Plan emoji, name, "CUSTOMIZED" amber pill if isOverridden
  • Edit / Reset buttons (Reset only when overridden)
  • Eight fields:
    • Max Projects (number)
    • Max Members (number)
    • Daily Credits (number)
    • Monthly Credits (number)
    • Max File Size (MB; stored bytes, displayed KB/MB/GB)
    • Custom Domains (toggle)
    • Analytics (toggle)
    • Priority Support (toggle)
  • "Last updated" timestamp

Save writes PUT /admin/plan-limits/:plan with the full payload; Reset writes PUT /admin/plan-limits/:plan/reset to restore the PLAN_LIMITS defaults from @doable/shared.

Sub-tab: Plan Defaults (AI)

Sets the default model + provider per plan tier; new workspaces inherit it, and Apply to Existing backfills.

Per plan card:

  • Plan emoji, name, sub-line summary ("Copilot · gpt-4o" or "No default configured")
  • Configure button opens inline PlanEditForm
  • Apply to Existing button (only when configured) → POST /admin/platform-ai-defaults/apply-to-existing with { plan, overwrite }
  • Source toggle: None · GitHub Copilot · Custom Provider
  • If Copilot: account select, model select (dynamic via useCopilotModels) with "Type custom model ID" sentinel
  • If Custom: provider select, model select (dynamic via useProviderModels) with the same custom sentinel
  • Save → PUT /admin/platform-ai-defaults/:plan

Footer toggle: "Overwrite existing workspace AI settings when applying to existing" controls the overwrite flag on backfill.

Common tasks

  • Set Pro to 1 000 daily credits, 30 000 monthly, 50 max projects
  • Mark Custom Domains and Priority Support on for Business
  • Reset Free back to hardcoded defaults
  • Configure Pro plan default AI = Copilot account "acme-bot" + model "claude-sonnet-4"
  • Backfill all existing Pro workspaces with the new default (overwrite off so nobody loses their override)

Watch for: the Apply to Existing + Overwrite combination is the only place where one button can change settings across every existing workspace at once. Read the footer toggle twice before clicking Apply.

AI Tools

URL: /admin?tab=tools Reference: operations/platform-admin/tools.md

This tab controls which tools an AI mode is allowed to call. It is the platform-wide whitelist that gates Copilot and Provider runs.

Default mode catalogue (from modeToolQueries)

  • Strategize (plan): typically read-only / planning tools
  • Build (build): full file create/edit + deploy tools
  • Custom modes can be added (lowercase alphanumeric / _-)

Per-mode card

  • Mode icon (purple Wrench for plan, brand Wrench otherwise)
  • Mode label, code-pill, and "N tools" count
  • Description (if set)
  • Configure button enters edit mode
  • Trash icon deletes the mode (allowed only if not plan or build; confirm dialog)
  • In view: pills showing currently allowed tools
  • In edit:
    • Doable tools grid (KNOWN_TOOLS.category === "doable"): create_file, edit_file, read_file, list_files, install_package, deploy_preview, ask_clarification, create_plan, mark_step_complete, provision_supabase, request_integration, search_files
    • SDK tools grid (category === "sdk"): view, grep, glob, ask_user, report_intent, bash, edit
    • Each tool toggles in/out of editAllowedTools
    • Description textarea (max 500 chars)
    • Save → PUT /admin/tools/modes/:mode; Cancel exits edit mode

Adding a mode

  • Add Mode reveals an inline form
  • Input is normalised to [a-z0-9_-]; the server validates with ^[a-z][a-z0-9_-]{0,49}$
  • POST/PUT creates an empty mode and auto-opens it for editing

Common tasks

  • Disable bash for Strategize mode
  • Add a "review" mode that only allows view, grep, glob
  • Strip deploy_preview out of Build during a vendor outage
  • Delete a deprecated mode (falls back to hardcoded defaults)

Watch for: changes take effect on new sessions within 60 seconds. Mid-session sessions keep their existing tool list. The MCP server registry is TBD: there is no platform-wide MCP-server-add UI in this tab today. The CLAUDE.md note about MCP-apps compatibility refers to the surface that lives elsewhere in workspace AI settings.

MFA

URL: /admin?tab=mfa Reference: User Guide → Two-Factor Auth; no dedicated ops stub yet

MFA v1 shipped 2026-05-12: TOTP plus recovery codes, opt-in only, admin reset only. The schema is extensible for WebAuthn and required-policy later.

Controls visible

  • Info card explaining MFA is opt-in and user-controlled
  • Header row: User · Enrolled · Last used · Recovery
  • Per-row: display name + email, enrolled date, last-used date, "N left" recovery code count, Reset button
  • Reset opens a confirm dialog that spells out exactly what will happen:

This will remove all MFA factors and recovery codes for this user, and sign them out of every active session. They will be able to sign in with just their password until they enroll again.

  • The reset action calls apiAdminResetUserMfa(userId) and audit-logs action="mfa.reset" in admin_audit_log

Common tasks

  • See who has MFA enabled and when they last used it
  • Reset MFA for a user who lost both their authenticator and recovery codes
  • Audit MFA reset events via /admin/audit/actions

Watch for: Reset is the only destructive action; you cannot enroll MFA on someone's behalf. You cannot enforce MFA platform-wide from this UI yet; that is TBD.

Thumbnails

URL: /admin?tab=thumbnails Reference: operations/platform-admin/ops.md

Thumbnails are generated by Puppeteer; this tab is the operator's view into that pipeline. The panel comes from ThumbnailsPanel in admin-panels.tsx.

Controls visible

  • Refresh thumbnail logs button
  • Per-row table: project name, status (ok / failed), preview URL, duration in ms, triggered_by, created_at, last error
  • Generate Missing Thumbnails button → POST /admin/thumbnails/generate-missing runs in the background and returns the count

Common tasks

  • Backfill missing thumbnails after a deploy
  • Investigate a single project whose card is stuck on the placeholder

Watch for: Puppeteer needs Chrome dependencies. server-setup.sh installs them, but if you migrated the install manually, missing libs show up as failed rows here. Re-run the script's apt-get install block to fix.

Sessions

URL: /admin?tab=sessions Reference: operations/platform-admin/ops.md

Live snapshot of the in-process Copilot engine pool. Panel comes from CopilotSessionsPanel in admin-panels.tsx.

Controls visible

  • Live process snapshot: pool size out of max engines (20), heap used / total, RSS, uptime
  • Engine list per project (project name + chat sessions)
  • Per-engine Terminate button; Terminate all red button

Every terminate is audit-logged via recordAdminAction().

Common tasks

  • Kill a stuck Copilot engine on a single project
  • Inspect live RAM and engine count on the API process
  • Terminate all engines after a vendor outage so they reconnect cleanly

Watch for: terminate-all is heavy-handed; every running chat goes away. Use it sparingly. If a single project misbehaves, terminate that engine only.

Email

URL: /admin?tab=email Reference: operations/platform-admin/email.md

Manages outbound email: provider config, queue health, dead-letter handling.

Provider configuration card

  • Provider type select: SMTP, Resend, Google (ProviderType = "smtp" | "resend" | "google")
  • Common fields: label, from_address
  • SMTP fields:
    • Service dropdown: SMTP_SERVICES includes Gmail, SendGrid, Mailgun, SES, Zoho, Outlook365, Fastmail, Postmark, Mandrill, SparkPost, Yahoo, iCloud, AOL, Godaddy, 1und1, DynectEmail, Hotmail, QQ, QQex, 126, 163, plus Custom (manual SMTP) which exposes host + port inputs
    • User, Pass
  • Resend: single apiKey field
  • Google: OAuth flow; ?gmail=connected triggers the success toast after callback
  • Buttons: Save (POST /admin/email/config), Test email (POST /admin/email/test), Verify credentials, Delete provider

Queue stats card - Counters: pending · processing · sent · failed · dead - Refresh button → GET /admin/email/queue-stats

Queue browser - Paginated table of queue items (page, limit, total) - Columns: To, Subject, Status, Attempts (n/max), From, Template, Created, Sent, Next retry, Last error - Per-row: Preview (HTML + text body), Retry (RotateCcw icon), Delete (Trash2 icon)

Common tasks

  • Hook up Gmail OAuth as the platform sender so signup-approval emails deliver
  • Switch SMTP service from SendGrid to Resend
  • Resend a failed welcome email
  • Inspect the dead-letter queue and purge stale rows

Watch for: verify your sending domain has SPF/DKIM before broadcasting to large lists, or the whole batch ends up in failed. The queue browser is the only place to recover individual messages.

The side surfaces

Seven dedicated URLs that live outside the main tabbed page. Each has its own purpose, audience, and footprint.

/admin/audit

URL: /admin/audit Sub-routes: /admin/audit/[sessionId] (single transcript), /admin/audit/actions (admin action log) Reference: operations/audit-logs.md

The prompt-and-conversation audit. Header text reads: "Every search and view you perform is recorded for compliance." Read this guide carefully: every action you take here is itself audited.

Stats row (top of page)

AuditStats fields: total_sessions, total_messages, total_users, messages_24h, messages_7d, sessions_24h.

Search form

URL-param-driven; the form fields populate query params and the page reloads via the queryString-keyed effect. Searches include free-text queries against the conversation body.

Conversation table

Columns: session_id, project name + workspace name, user email / display name, mode (plan / build / custom), created_at, updated_at, last_message_at, message_count, last_user_excerpt (truncated), last_assistant_excerpt (truncated). Row click → /admin/audit/[sessionId] shows the full transcript.

/admin/audit/actions (admin action log)

Columns: timestamp, actor (id, email, role, name), action (enum), resource_type / id, target user / workspace / project, details JSON, client_ip, user_agent.

Filters:

  • Actor ID (UUID input)
  • Action dropdown with known events:
    • audit.conversations.search
    • audit.conversation.view
    • audit.messages.search
    • audit.actions.search
    • audit.stats.view
  • From / To datetime-local pickers

Other writes that flow through recordAdminAction() are also visible: mfa.reset, sandbox edits, OAuth app changes, AI allocations, plan-limit edits.

Error states

  • 404 → "Audit log is not yet enabled on this platform" (server feature gate not flipped)
  • Other 5xx → "Audit endpoint is unavailable (HTTP n)" with Retry button

Common tasks

  • Search every conversation containing "OpenAI API key" to find users pasting secrets
  • Pull all sessions by a specific user in the last 24 hours
  • Audit which platform admin viewed which session and when (compliance review)
  • Verify nobody is abusing audit reads; every viewer is also recorded

Watch for: this is the most sensitive screen in the panel. Treat every search as a logged event. If your company has a compliance officer, plan a quarterly review of /admin/audit/actions.

/admin/chat

URL: /admin/chat Reference: mirrors /admin/audit; see operations/audit-logs.md

A redacted, audit-logged view of all AI chat sessions. Functionally close to /admin/audit but with redaction tuned for daily ops viewing rather than compliance review.

Common tasks

  • Spot-check what users are actually using AI for
  • Find chat sessions that errored repeatedly so you can route a bug fix

Watch for: redaction is conservative. If you need the raw transcript, switch to /admin/audit, and accept that the access is logged.

/admin/dev-servers

URL: /admin/dev-servers Reference: architecture/sandboxing.md

Live snapshot of all sandbox dev servers. Each preview running inside a project (vite, next dev) shows up here.

Controls visible (typical)

  • Per-project row: project name, workspace, owner, sandbox PID, CPU, memory, uptime, last-active timestamp
  • Per-row terminate / restart actions

On hardened servers, preview vite runs under bwrap --uid 9052. The dev-servers list is your window into that pool.

Common tasks

  • Identify a runaway preview process eating memory
  • Terminate a dev server before doing a server-wide restart
  • Confirm a recently-published project has shed its dev server

Watch for: dev servers come and go on every save. A row that has been alive for hours when nobody is editing is unusual; investigate.

/admin/moderation

URL: /admin/moderation Reference: User Guide → Marketplace

Moderation queue for marketplace submissions. Projects published as marketplace listings land here until a platform admin reviews them.

Controls visible (typical)

  • Per-submission row: project name, author, submission timestamp, status
  • Approve / Reject actions with a reason field
  • Preview link to the submitted project

Common tasks

  • Approve a marketplace listing
  • Reject a submission with a reason (the author sees it)
  • Investigate a flagged listing reported by users

Watch for: rejection reasons are user-visible. Be specific and respectful; these are creators with skin in the game.

/admin/projects

URL: /admin/projects Reference: user-guide/overview.md

A flat list of every project across every workspace. Useful when you need to find a project by name without knowing whose workspace it lives in.

Controls visible (typical)

  • Search by project name
  • Filter by workspace, owner, plan, status
  • Per-row: name, workspace, owner, last updated, framework, published-or-not
  • Row click → opens the project in the editor (you appear as a platform-admin viewer)

Common tasks

  • Locate a project a user is asking about on Discord without knowing their workspace
  • Spot orphaned projects after a workspace owner leaves
  • Audit which workspaces have the most projects on the Free plan (capacity planning)

Watch for: opening a project here grants you read access via platform admin, and your viewing is visible to the owner. Behave accordingly.

/admin/runtime

URL: /admin/runtime Reference: operations/platform-admin/ops.md

Cross-workspace listing of published apps and dev servers with live cgroup metrics. Backed by GET /admin/runtime/instances which joins project_runtime with project, workspace, owner, and live metrics.

Controls visible

  • Table of runtime instances with CPU, memory, uptime, owner workspace, owner user
  • Filter by kind (published / dev), status, workspace
  • Per-row terminate / restart

Common tasks

  • Identify the published app that just spiked memory
  • Confirm uptime across the fleet before a deploy
  • Locate the workspace that owns a noisy preview

Watch for: terminating a published app takes the site offline until the next request restarts it. Restart is usually safer than terminate.

/admin/trace

URL: /admin/trace Sub-routes: /admin/trace/[traceId] Reference: the trace tooling overview; the project memory note for the OMC trace tool applies in spirit

X-Ray / OpenTelemetry trace search. Per CLAUDE.md: "USE TRACING/XRAY INFRASTRUCTURE AVAILABLE FOR IDENTIFYING ISSUES OR BUGS WHEN YOU HAVE TO. DO NOT GUESS BY SEEING CODE." This is where that infrastructure lives in the UI.

Controls visible

  • Search by trace ID, user ID, project ID, timestamp range, status code, error class
  • Per-row trace summary with duration, top span, error count
  • Click into a trace → flame graph + per-span detail

Common tasks

  • Reproduce a user's bug from their trace ID
  • Find the slowest endpoint in the last hour
  • Investigate an error class spike during an incident

Watch for: traces contain user-supplied text: prompts, errors, file paths. They are sensitive. Always zap root causes through traces rather than working around bugs. Treat the trace UI like the audit UI: use it, and assume you are observed.