Your Production Database Is on Fire and You Don't Know It

It's 2 AM and your on-call phone rings. Users can't log in. The app is returning 500s. You SSH into production and start guessing. Is the database up? Is it out of connections? Is something hogging the CPU? You open psql and start typing queries from memory, hoping you remember the right system views.

This is what happens when you don't have an admin dashboard. Not a Datadog. Not a Grafana. An admin dashboard — a page in your actual application where you can see the health of your infrastructure, your database, your active queries, and your users. Built into your app, behind your auth, accessible to the people who need it.

What you can't see is what kills you

Most applications have zero operational visibility beyond what the hosting provider gives you. You get a CPU graph and a memory graph. Maybe request counts. But you don't get:

- **Database health** — commits vs rollbacks, cache hit ratio, database size on disk - **Active queries** — what's running right now, how long has it been running, who started it - **Connection pool status** — how many connections are in use, how many are idle, are you about to run out - **Runaway query detection** — which queries have been running for more than 30 seconds and are probably stuck - **Service health checks** — is Redis up? Is the payment API reachable? Is the email service responding?

Without this, every production incident starts with 10 minutes of detective work just to understand what's wrong. With it, you open the dashboard and the answer is usually staring at you.

The queries you should always have

-- Active queries with duration
SELECT pid, now() - pg_stat_activity.query_start AS duration,
       state, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

-- Database stats
SELECT xact_commit, xact_rollback,
       blks_hit::float / (blks_hit + blks_read) AS cache_ratio,
       pg_size_pretty(pg_database_size(current_database())) AS db_size
FROM pg_stat_database
WHERE datname = current_database();

Every Postgres-backed application should be able to answer these questions instantly:

**How healthy is the database?** Transaction commits vs rollbacks tells you if your app is erroring out. The cache hit ratio tells you if your working set fits in memory (below 95% is a red flag). Database size tells you if you're about to hit a storage limit.

**What's running right now?** pg_stat_activity shows every active query with its duration, state, and the user who started it. This is the single most useful view during an incident — if a query has been running for 45 minutes, that's probably your problem.

**Can I kill it?** Yes. pg_terminate_backend() kills a specific connection. Your admin dashboard should have a button for this, gated behind super-admin auth. And a "terminate all long-running" button for the really bad days.

Pluggable health checks

// Register checks for your infrastructure
const monitor = new InfrastructureMonitor();
monitor.register("postgres", makeDbCheck(pool));
monitor.register("redis", makeRedisCheck(redis));
monitor.register("stripe-api", makeHttpCheck("https://api.stripe.com/v1", 5000));
monitor.register("email-service", makeHttpCheck("https://api.resend.com", 3000));

// One endpoint returns everything
app.get("/api/admin/health", async (req, res) => {
  const results = await monitor.checkAll();
  res.json(results);
});

A health endpoint that returns {"status": "ok"} is useless. A health endpoint that checks every dependency and tells you which one is down is invaluable.

The pattern is simple: register named checks, each with a timeout. Run them all (or in parallel), collect the results, return a structured response. When everything is green, the response is boring. When Redis is down, you know immediately — without opening a Redis CLI.

The check functions themselves are trivial. A database check runs SELECT 1. A Redis check runs PING. An HTTP check hits a URL and checks for a 200. What matters is that they're registered in one place, run on every /health request, and the results are visible in your dashboard.

Why AI won't build this for you

Ask an AI assistant to "add an admin dashboard" and you'll get a React page with some cards and fake data. It won't know your database connection string. It won't query pg_stat_activity. It won't register health checks for your actual infrastructure. It'll give you a skeleton that looks like a dashboard but doesn't do anything.

The hard part isn't the UI — it's the operational queries, the health check plumbing, the connection pool monitoring, and the super-admin auth gating. These require understanding your specific infrastructure, not just generating components.

One command to install

$ stablestack add-admin-dashboard
Created stablestack_admin_dashboard/monitor.py
Created stablestack_admin_dashboard/models.py
Created stablestack_admin_dashboard/api.py
Created stablestack_admin_dashboard/ui/AdminDashboard.tsx
Created .claude/commands/admin-dashboard.md

StableStack's admin dashboard scaffold generates the full operational stack — health monitoring, database management, user admin, and React UI — in one command:

What you get

**Infrastructure monitor** — A pluggable health check system with factory functions for Postgres, Redis, and HTTP endpoints. Register your checks at startup, query them from one endpoint. Each check has a name, timeout, and returns healthy/unhealthy with a reason.

**Database operations API** — Endpoints for database stats (commits, rollbacks, cache ratio, size), active query listing with duration, single query termination, and bulk termination of long-running queries. All behind super-admin auth.

**User admin** — List users with pagination and search, toggle admin status. See who's in your system and manage access without a database console.

**React dashboard** — A drop-in AdminDashboard component with tabs for Health, Database, and Active Queries. Green/red status indicators, kill buttons, refresh on demand. Framework-agnostic with inline styles.

**Token manager integration** — If you've also installed the token manager scaffold, the admin dashboard auto-detects it and adds a Tokens tab showing every credential's health.

**Claude Code slash command** — Use /admin-dashboard and Claude Code wires it into your app: registers health checks for your detected infrastructure, mounts the routes behind auth, and adds the dashboard to your UI.

Available in both Python (FastAPI) and TypeScript (Express). Auto-detects your project language.

What to do right now

If you can't answer these questions about your production application right now, you need an admin dashboard:

1. What's the database cache hit ratio? (If you don't know, it might be terrible.) 2. Are there any queries running longer than 30 seconds? (There probably are.) 3. How many database connections are in use right now? (If you're near the limit, the next traffic spike will knock you offline.) 4. Is Redis responding? Is your payment API reachable? (You'll find out when users do, unless you check proactively.)

You don't need Datadog to answer these questions. You need a page in your app that queries your own infrastructure and shows you the results. That's what the admin dashboard scaffold builds.