Workspace
Pulse health dashboard
Engine-aware overview — sessions, cache stats, and hotspots after connect.
The story
Marcus connects to staging Postgres at 9:02 a.m. and opens Pulse before Tables — sessions, cache hit ratios, and replication lag tell him whether last night's deploy is healthy.
Pulse is engine-aware: Postgres shows pg_stat activity; MongoDB surfaces cluster context; Redis highlights memory pressure. One panel, different dialects — not a generic dashboard pretending every database is the same.
When Pulse looks wrong, Marcus drills into Catalog or Query lab with context already in mind.
Bridge path: /
Step 1
The morning health check
Active sessions spike — Marcus sees long-running queries before users complain. He copies pid context into Query lab and cancels the offender.
Pulse is the coffee cup panel: quick, habitual, decisive.
Engine-aware overview — sessions, cache stats, and hotspots after connect. Opens automatically after database connect at /. Metrics adapt per engine from live introspection.
Step 2
How Pulse changes per engine
On Redis, memory and keyspace stats matter; on Postgres, connections and buffer cache; on MongoDB, opcounters hint at load. Marcus never expects identical widgets — he expects the right widgets.
Switching saved connections refreshes Pulse without restart.
Engine-specific metrics from native stats tables or APIs. No faux SQL metrics on document stores.
Step 3
Act before the incident page
Replication lag amber on Pulse sends Marcus to backups and query plans before paging. The story ends with no 3 a.m. wake-up — or at least a shorter one.
Pulse links into deeper catalog panels when numbers look off.
Threshold-style highlighting where supported. Pair with Ops → Backups and Catalog → Indexes for follow-through.
postgresql://, ssh://, sftp://, s3://, or smtp:// examples.Related connections