Internal Ops Dashboard — Backlog & Scorecard

Last updated: 2026-06-28 Analyst: Codebase audit (apps/internal-api + apps/internal-dashboard, full source review)

Scorecard

Overall: 7.5 / 10

Bugs

B1 — Live-only queries will timeout at scale (rollup cron disabled)

Severity: High Location: apps/internal-api/src/services/spend.ts, wrangler.toml

The rollup cron (0 2 * * *) is commented out in wrangler.toml (Cloudflare account is at the 5-cron limit). All analytics reads — especially netConsumed() and netSpendByService() — perform live scans of credit_transactions filtered by created_at. At even a few million rows, these queries take 5–10 seconds and will hit the 30-second Worker CPU limit. There is also no index on (created_at) WHERE amount < 0 to speed up debit-only scans.

Recommended index:

CREATE INDEX CONCURRENTLY credit_tx_created_at_debit_idx
  ON credit_transactions (created_at) WHERE amount < 0;

B2 — Note add triggers second view_customer audit entry via refetch

Severity: Low Location: apps/internal-dashboard/src/app/customers/[id]/page.tsx

After a staff member adds a note, the page calls refetch() which re-calls GET /api/admin/customers/:id. The route handler writes view_customer to accessLog on every call. A staff member who adds 5 notes generates 6 audit entries (1 initial view + 5 refetch-triggered views). The audit trail overstates how many times the profile was independently accessed.

Fix: Only log view_customer on GET when the request does NOT include a ?refetch=notes marker (or separate the notes endpoint from the full profile).

B3 — Keyset cursor encodes Date object: timezone-dependent serialisation

Severity: Low Location: apps/internal-api/src/services/admin-analytics.ts — listCustomers()

The pagination cursor is base64(JSON.stringify({ c: createdAt, id })). createdAt is a JavaScript Date object. JSON.stringify(new Date()) produces an ISO-8601 string in UTC — but if the DB driver returns a Date already adjusted to a non-UTC timezone, the comparison >= cursor.c on subsequent pages uses a different reference time. This could produce duplicate or skipped rows in rare environments where the Neon driver or Node.js runtime uses local timezone for Date construction.

B4 — listAccessLog limit param not validated; accepts any integer

Severity: Low Location: apps/internal-api/src/routes/admin.ts → GET /audit

The route reads limit = Number(c.req.query("limit") ?? "200") and passes it directly to listAccessLog(opsDb, limit). There is no cap validation — a caller can request limit=1000000 and force a full table scan. The listAccessLog service has a documented max of 500 but doesn't enforce it in code.

B5 — safe() silently hides missing tables on Growth page

Severity: Low Location: apps/internal-api/src/services/admin-analytics.ts → getGrowth()

Waitlist and feedback queries are wrapped in safe() which returns null on error. If the waitlist or feedback tables don't exist (e.g., a staging DB), the Growth page renders empty sections with no explanation. Staff see no waitlist data and may believe there are zero signups, when actually the table is absent. A null result should surface a visible warning in the UI.

B6 — STAFF_EMAILS allowlist not whitespace-trimmed

Severity: Low Location: apps/internal-api/src/middleware/staff-auth.ts

The allowlist is parsed with STAFF_EMAILS.split(",") but .trim() is not applied to each entry. If the secret is set as "founder@vlozi.app, hello@vlozi.app" (space after comma), " hello@vlozi.app" with a leading space will never match the JWT email claim. The failure mode is silent 403s for valid staff members.

B7 — No access log retention policy

Severity: Low Location: apps/internal-api/src/db/schema.ts → accessLog

The accessLog table has no TTL, cleanup job, or partitioning strategy. At 50 customer-profile views per day (conservative for a growing team), it accumulates 18,000+ rows/year. Within 3–4 years this degrades audit query performance. No retention decision is enforced at the schema or infrastructure level.

Areas of Improvement

A1 — Re-enable rollup cron + add credit_tx index

The single most important performance improvement. Free a cron slot (or upgrade account tier), uncomment [triggers] in wrangler.toml, and add the index. This drops overview/credits/growth query time from seconds to milliseconds once rolled up.

A2 — Add customer mutations (suspend, adjust credits)

Current state: read-only. Phase 2 scope includes suspending a tenant and issuing credit adjustments. With credit helpers already in the service and the audit trail built, the infrastructure is ready — only the route and UI components are missing.

A3 — Add test coverage

Both apps/internal-api and apps/internal-dashboard have zero tests. At minimum:

• admin-analytics.ts service functions (spend computation, MRR formula, keyset cursor)
• Staff auth middleware (JWT rejection, allowlist miss)
• spend.ts net spend formula (hold/capture/void combinations)

A4 — Move STAFF_EMAILS to ops DB table

Managing staff access via an env var requires a Worker redeployment every time someone joins or leaves. A staffAccess table in ops DB with (email, active, addedBy, addedAt) rows would allow runtime management and produce an audit trail of its own.

A5 — Extract credit helpers to @repo/core-billing

apps/internal-api/src/services/credit-helpers.ts duplicates logic from the manager app. A shared @repo/core-billing package (already referenced in TODOs) would eliminate the drift risk.

A6 — Enable ACCESS_AUD in production

The ACCESS_AUD env var is defined and the JWT validation code supports it, but it's not set in production. Audience pinning binds the JWT to this specific Cloudflare Access application — a leaked JWT from another Access app cannot be replayed here. Set ACCESS_AUD to the Application Audience (AUD) tag from the Cloudflare Access dashboard.

A7 — Log all page views for full accountability

Currently only view_customer and add_note are logged. Revenue, Credits, and Growth pages that show aggregate sensitive data (MRR, top consumers) are not logged. For a complete audit trail, every authenticated page request should write an entry — even if the target is null for non-customer-specific pages.

Known Deferred Items (Not Bugs)