Database Monitoring Setup Guide

Before you start

Database checks do not run from HostTracker's distributed public monitoring network the way an Http or Ping check does, so this form has no Monitoring Locations section at all. Instead, every check dials your server from HostTracker's own private checking infrastructure, using two fixed source addresses: 4.207.101.172 and 20.107.152.200 (North Europe). Before you save the monitor, add both addresses to your database server's firewall or security group allow list, and make sure the server accepts connections on its port from the public internet, or at least from those two addresses. If the port is not reachable, every check fails with a connection error regardless of how the rest of the monitor is configured.

Set up the monitoring account itself before you start: create a database user dedicated to the check, grant it only what the check needs (typically just the ability to connect, plus SELECT on whatever table your query touches), and avoid reusing an application or admin account. If the query you plan to run changes data, give that account write access to only the specific table involved, nothing wider.

Target database

Three fields identify what the check connects to, and sit above the collapsible sections since they are mandatory:

• Server type - a dropdown of the supported providers: Microsoft SQL Server, Oracle, MySQL, PostgreSQL, and Firebird.
• Server : Port - the hostname or IP of the database server, and its port. Changing the server type fills in that provider's conventional default port automatically (1433 for SQL Server, 1521 for Oracle, 3306 for MySQL, 5432 for PostgreSQL, 3050 for Firebird) - you only need to override it if your server listens somewhere else.
• Database (or, for Oracle, Service and Instance name (SID) instead) - the name of the database to connect to. For Oracle you can supply the service name, the SID, or both, depending on how your listener is configured.

Below that, an optional Name field lets you label the monitor for alerts, reports and widgets - useful once you have more than one database check and need to tell them apart at a glance.

Main Settings

This group holds the schedule and the two general-purpose toggles every check type shares:

• Interval - how often the check runs, offered from 10 minutes up to 24 hours (10, 15, 30, 45 minutes, then 1, 2, 4, 6, 12 and 24 hours), plus a cron-schedule alternative for less regular timing. Database checks do not offer the sub-10-minute intervals some other check types do.
• Tags - free-form labels for grouping and filtering monitors elsewhere in the dashboard.
• Full Log - saves every individual check result instead of only grouped summaries, useful when you need to see exact response times or values over time rather than just up/down history.
• Open Stats - makes this monitor's statistics and log page shareable, including with people who are not signed in.

Connection

With the target already set above, this section covers how the check authenticates and how it handles a failed connection attempt:

• DB user name and DB user password - the credentials for the monitoring account described above. Both are optional: leave them blank if your database allows a trust or anonymous connection from an allow-listed address, which some internal setups do.
• The panel itself displays the two source addresses checks are made from (4.207.101.172, 20.107.152.200) with a reminder to include them in your database firewall's allow list - this is the same requirement covered under Before you start, repeated here because it is exactly where the credentials live.
• Retry on connect fail - a switch, on by default, that retries the connection attempt once before marking the check as failed. It only covers the connection step itself, not the query.

Response Validation

This is the key decision in a Database check: whether you are testing that the connection works, or that a specific query still behaves as expected.

• Query - leave this empty and the check only tests the connection: it opens, and closes, and that is the whole check. Fill in any SQL your monitoring account is allowed to run - a SELECT, or a data-changing statement like UPDATE, DELETE or INSERT - and the check runs it on every poll and can judge the result.
• Query result (only shown once a query is entered) - choose Scalar value to read whatever is in the first column of the first row returned (the natural choice for a SELECT, or for an UPDATE/INSERT that uses an OUTPUT clause), or Row count to read how many rows were affected (the natural choice for a plain UPDATE, DELETE or INSERT with no result set of its own).
• Result verification - a comparison to apply to that value: No verification (the query only has to run without error), Equal to, Not equal to, Greater than, Less than, In range, or Out of range. The greater/less-than and range options add one or two number fields, with an included/excluded toggle on each range boundary.
• Retry query on error - a switch, on by default, that retries the query execution once if it fails, separate from the connection-level retry above.

Choose connection-only when you just need to know the database is reachable and accepting connections - it catches outright outages. Choose a query with result verification when reachability alone would miss the real problem: a table that stopped receiving new rows, a stored count drifting outside a normal range, or a specific piece of data that should always be present.

Alert Subscriptions

Choose which contacts hear about this monitor and for which events - Up, Down, and Repeat (a repeated reminder while the check stays down). A single switch subscribes every contact to Up/Down at once, or you can pick individual contacts and events from the table below it.

Report Subscriptions

Separately from alerts, choose who receives periodic uptime and performance reports for this monitor - Daily, Weekly or Monthly - by email.

Worked example

Watching a production PostgreSQL database an application depends on: Server type PostgreSQL, Server : Port db.example.com:5432, Database myapp_prod. A dedicated read-only account is entered under Connection, and both source IPs are added to the database's security group first. The Query field holds SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Query result is Scalar value, and Result verification is Greater than with a limit of 0 - if no orders have been recorded in the last hour, something upstream has stopped writing, and the check goes Down even though the database is reachable. Interval is 15 minutes, both Retry switches stay on so a transient blip does not trigger a false alert, alerts go to the whole team's Up/Down subscription, and a weekly report goes to the account owner.

Troubleshooting

• Every check fails with a connection error. The most common cause is a firewall that has not been opened for HostTracker's two source addresses - confirm 4.207.101.172 and 20.107.152.200 are allow-listed, and that the port itself is open to them.
• Connection succeeds but authentication fails. Check the DB user name and password are correct and that the account has permission to connect to the named database, not only to the server.
• A query that works fine in a client tool returns nothing here. A plain UPDATE, DELETE or INSERT with no OUTPUT clause has no result set to read as a Scalar value - switch Query result to Row count, or add an OUTPUT clause if you need the row's data back.
• Result verification never triggers. Confirm the comparison and the number fields match the range you expect: a boundary set to excluded rather than included is an easy way to make a limit never fire.
• Occasional single failures you suspect are transient. Both retry switches are on by default and already retry once before failing the check - if failures are still frequent, the problem is more likely a real connectivity or query issue than noise.

Related

• Database query monitoring - the product page for this check type.
• CPU, RAM and disk monitoring guide - another check that runs from HostTracker's private infrastructure rather than the public network, useful alongside a database check on the same server.
• SNMP monitoring guide - for reading values directly off network hardware instead of a database.
• Assertion mode and response-validation rules - the response-validation rule language used elsewhere in HostTracker's check types.
• All HostTracker monitoring features - see every check type side by side.
• 503 Service Unavailable - the status a site returns when the database behind it stops answering.
• All monitoring guides - the setup guide for every other check type.