Database Health

Release pending. This guide describes the Database Health release being verified. Availability in your deployment is not yet confirmed.

Database Health has two setup options: connect to MongoDB, PostgreSQL or MySQL with a dedicated monitoring user, or send measurements from your own network through REST or the optional Node.js reporter. Both feed a private dashboard under Internal → Database Health. The existing error heatmap remains a separate Internal page.

Choose how to connect

Option	Use it for	What you need
Connect in the dashboard	Reachability, probe latency and supported server connection counters	A reachable database endpoint, verified TLS and a dedicated monitoring login
REST server observations	Databases reachable only inside your network	Your own collector and a page-scoped ingest key
Application reporter	Pool demand, idle connections, waiting and supported acquisition measurements	Instrument the application pool using a supported adapter, or implement the versioned REST pool contract

The direct connection uses the database protocol. It does not use the MongoDB Atlas Administration API. Support follows the database engine and permissions; it is not a claim that every managed provider or engine version has been verified. Other engines need a supported adapter before they can be selected.

Connect from the dashboard

1. Select Connect a database and choose MongoDB, PostgreSQL or MySQL.
2. Enter the hostname, database and dedicated monitoring credentials. MongoDB SRV discovery is available for mongodb+srv hosts. A custom certificate authority can be supplied; certificate and hostname verification remain required.
3. Choose a check interval from one to five minutes. New connections default to one minute; existing connections retain five minutes unless changed.
4. Select Test connection, review any unavailable diagnostics, then save. A successful connection test does not guarantee every diagnostic is permitted.
5. Check the saved row for its last check, next due time and measurements. Change the interval without entering credentials again. Use Manage connection to pause, resume, replace credentials or disconnect.

Public-network destination checks reject private and loopback addresses. Use outbound REST reporting when the database is private. Saving a connection does not change database settings or application pools.

What the direct checks measure

Engine	Measurements	Monitoring access
MongoDB	Ping latency, current connections and a connection limit when reported	serverStatus privilege on the cluster resource; clusterMonitor includes it and broader monitoring privileges
PostgreSQL	Probe latency, client connections, max_connections, active sessions and lock waits	CONNECT to the database; pg_read_all_stats for cross-session activity and lock-wait counts
MySQL	Probe latency, Threads_connected, Threads_running and max_connections	A login allowed to connect to the selected database; the fixed SHOW commands do not require administrative privileges

Unknown or restricted measurements stay unknown. A server connection total includes other clients and monitoring connections. These checks do not collect host CPU, memory, disks, query text, documents or replication diagnostics.

Check timing and history

Workers scan for due checks every ten seconds. A due time is a scheduling target, not a promise of execution at that exact second. Small jitter spreads load; temporary failures back off up to 30 minutes. Authentication, TLS, network-policy or unreadable-credential failures stop automatic checks until corrected or retried.

Each page supports up to 20 saved connections. Each connection retains at most 288 samples for up to 24 hours. At a one-minute interval the sample cap holds about 4.8 hours, so it does not guarantee a full day of history. The selected interval affects direct checks, not SDK reporting frequency.

Should I reduce the pool?

Server connection counts alone cannot answer this. Application evidence must show peak busy connections, waiting, failures, configured limits and enough continuous coverage. The dashboard may suggest a smaller pool for a controlled trial when that evidence supports it. It does not change pool settings or certify a production-safe size.

For multiple Cloud Run API and worker instances, include every relevant application pool and deployment revision. Validate a proposed change during representative traffic and overlapping deployments. PostgreSQL and MySQL adapters currently leave some required sizing evidence unknown, so the dashboard may correctly return insufficient data.

Price and access

Database Health is a separate optional feature at $3 per paid status page per month, charged linearly: two paid pages cost $6 per month for this feature before applicable discounts or tax. The account capability is database.health. Internal analytics remains a separate $7-per-account monthly feature for the error heatmap. Buying one does not imply the other.

Continue with the Database Health reporting reference for authentication, limits and SDK support.