Database monitoring

WatchTower15 monitors MySQL and MariaDB databases: their availability, restarts, connections, threads, queries, replication, slow queries and deadlocks, how fast their storage grows, how their schema changes, which statements cost them the most, what their slow query and error logs record, and what in their configuration, schema and security is worth a look. On Amazon RDS and Aurora, they can also read the host’s own CPU, memory, storage and disk figures from CloudWatch. The server agent you already run does the collecting, from your own servers.

Egress-only, always

WatchTower15 never connects into your network. Your agents connect out, to the database and to WatchTower15, exactly as they already do for server telemetry. You open nothing to us: no inbound rule, no public endpoint, no VPN. WatchTower15 is never granted anything either: no AWS role, no trust policy, no cross-account access, no credential. Whatever your collectors read in AWS, they read with their own instance role, from inside your account.

Where it runs

Pick where the database runs first. Each provider has its own setup page:

Provider	Engines	Page
Self-managed on Amazon EC2 — on a monitored server itself, or on another server in the same VPC	MySQL 5.7, 8.0, 8.4 · MariaDB 10.11	Self-managed on EC2
Amazon RDS for MySQL	MySQL 5.7, 8.0, 8.4	Amazon RDS and Aurora
Amazon Aurora MySQL	Aurora MySQL 2.x and 3.x	Amazon RDS and Aurora
Amazon RDS for MariaDB	MariaDB 10.6, 10.11	Amazon RDS and Aurora

Other providers — Google Cloud SQL, Azure, DigitalOcean, Akamai, Vultr, OVHcloud, Scaleway, UpCloud, Aiven, Oracle MySQL HeatWave and any other MySQL-compatible endpoint — are listed as Coming soon and cannot be set up yet. PlanetScale is not supported: it gives no SQL-level monitoring access.

What it collects — and never collects

Collected	Never collected
Up or down, and why (authentication, TLS, refused, timeout…)	Your data: no table of yours is read; sizes come from InnoDB’s statistics table mysql.innodb_table_stats and its tablespace and file views; the advisor reads InnoDB’s catalogue views (the names of tables, indexes and their columns), mysql.innodb_index_stats, performance_schema’s index-usage counts and, only with the optional account grant, six named columns of mysql.user, never a password hash
Restarts, and failovers to another server	Statement text, except normalised statements (literals replaced by ?) with Clear names; never literals, query samples or the processlist
Connections against max_connections, threads running	Passwords or keys: WatchTower15 stores only where your collectors find them
Queries by command, row operations, slow queries, temporary tables	View definitions
Buffer pool hit ratio, row lock waits, deadlocks, network bytes	Anything over a connection WatchTower15 opens: it opens none
Replica state and lag
Schema and table sizes, row estimates and growth, as keyed hashes; schema and table names only in Clear names mode
Schema structure — tables, columns, indexes, views and routines created, altered, renamed or dropped — as keyed hashes with column types in clear; names only in Clear names mode	Column defaults, comments and expressions, routine bodies, ENUM and SET members: only that one changed
Statement statistics from performance_schema — calls, time, rows examined and sent, index use and errors per normalised statement — as keyed hashes; statement text only in Clear names mode	The statement history tables, EXPLAIN plans, wait events and locks
The server’s version, a set of its variables, the grant tiers the monitoring user holds
Advisor facts, once a day or on Run now: tables without a primary key, redundant and unused indexes, row versions and the server certificate’s dates, as keyed hashes; names only in Clear names mode	Password hashes: the optional account grant names six columns of mysql.user, and the password hash is not one of them
With the optional account grant only: account names and their authentication settings (plugin, TLS requirement, password expiry and lock state), as keyed hashes; account names only in Clear names mode
The slow query and error logs, parsed on the server that reads them: each slow statement’s times and rows under a keyed hash, each error’s time, severity, code and subsystem; normalised statements, scrubbed messages and account names only in Clear names mode	A statement’s values, the client’s host and address, an error’s continuation lines (dumps, stack traces), mysql.slow_log and the general query log
On RDS and Aurora, with the read policy on your collectors’ role only: the host’s CPU, memory, storage, IOPS, latency, throughput, burst and credit balances, replica lag and database load from CloudWatch, the instance’s class, storage and role from the RDS API, and its slow and error log files	Anything in AWS beyond eight read actions: no write, no Performance Insights call, no CloudWatch Logs, nothing in another account

Rates are worked out on the collector, per second, from the server’s own counters; a counter reset (a restart, or FLUSH STATUS) is detected and never shows as a spike.

The monitoring user is read-only: the collector opens a read-only session and runs a fixed list of statements per engine version. The grant script grants nothing more.

Adding a database

Databases → Add database opens a five-step setup. Each step saves as you go: you can leave and come back to a database that is still a draft.

At your organisation’s database limit, Add database is disabled, and a message under the page title says why.

1. Provider — the name, and where it runs.
2. Connection — the engine and version, how the collectors reach it (socket, loopback, private network, or a public endpoint), TLS and the certificate authority. For a self-managed database, the server it runs on.
3. Collectors — which of your servers collect it: a pool.
4. Credentials — the privacy mode and redaction key, where the collectors find the credentials, the grant script to run, and a network checklist. On RDS and Aurora, an optional Cloud metrics section gives the read policy and its cost.
5. Verify — every candidate connects once and reports what it found; on RDS and Aurora, with its Cloud metrics: check beside it.

Changes reach a collector in about 15–35 seconds: its next telemetry push or heartbeat. Verify waits 2 minutes for each candidate; one that has not answered by then shows No answer within 2 minutes (its agent is likely offline, still restarting or upgrading, or cannot reach WatchTower15), and Test again asks it once more.

A pool server that cannot collect right now — its agent stopped, no heartbeat in the last 90 seconds, monitoring paused, an agent that needs an upgrade, or one awaiting approval — is not asked. Verify lists it under Not collecting with the reason and when it was last heard from. A server an Auto Scaling group replaced keeps its tags, so it stays there until you delete it from Servers or remove the pool’s tags from it.

Adding a database needs a payment method on the account. A draft is not monitored, not billed and not counted against your limits: completing the setup, at Verify, is when it starts to count.

Statuses

Status	Means
Draft	Setup not complete. Nothing collects, nothing is billed.
Awaiting collector	No server in the pool can collect right now: none is eligible. Nothing is billed for that time, except the hours of data the last collector kept while cut off from WatchTower15 and delivers later (see Pausing, deleting, billing).
Verifying	The candidates are probing it.
Active	A collector reports it.
Failing	The collector cannot get an answer: the reason (for example auth_failed, tls_failed, timeout) shows in a banner under the tab bar, on every tab, with what to check, and beside the status on the Info tab’s Instance card.
Paused	Paused by you: nothing is collected, no alarm is evaluated and nothing is billed.

The database’s page

Each database has its own page, reached from Databases. Its header is one line: the database’s name, its alarm counts — Alarms · N Critical · N Warning · N OK — and, if you can edit the database, Setup, which opens the setup steps. Each count opens the Alarms tab, filtered to it, and the counts refresh every minute. While monitoring is paused they are dimmed and OK reads No data. Hovering over them says how many of the firing alarms are acknowledged and how many are inactive.

Under the header is the tab bar. The breadcrumbs, the header and the tab bar stay pinned to the top of the window as you scroll, with a shadow under them once the page scrolls beneath. Banners under the tab bar say when the database is failing, with the reason and what to check, when no server in its pool can collect it (No server can collect it.), when monitoring is paused, when the endpoint mixes several servers, and when a collector logs in over-privileged. They show on every tab.

Each tab has its own address, so a link opens the tab it names. An address ending in /performance opens the Overview, and one ending in /telemetry opens it on its Capacity view.

Tab	What it holds
Overview	The Now gauges, Monitoring coverage among them, and the data coverage over 30 days, in one card; then the Telemetry card: the Performance charts and, on RDS and Aurora, a Capacity view with the host metrics from CloudWatch. See The Overview
Storage & growth	Its sizes, growth and days to full: see Storage and growth
Schema changes	See Schema-change history
Queries	Its top statements, statement load and average latency: see Query analytics. The time range is the one the Overview charts, back to 30 days
Advisor	Its findings about configuration, schema, workload and hardening, with Run now: see Advisor
Logs	Its slow queries and error log: at the head, the window’s Slow statements logged and Error-log errors; then one log at a time, with its histogram, its lines, filters, storm summaries and the daily budget’s notice. See Slow and error logs. The time range is the one the Overview charts, back to 30 days
Alarms	Its alarms, as tiles
Incidents	Every incident on the database that was open at any point in the time range, filtered by Active · Resolved · All with a count in each, as on a server’s page: see A database’s incidents. The time range is the one the Overview charts
Collectors	Test again, Reassign now, Pause or Resume; the Collectors card, with each pool member’s role and last probe; and the Collector history
Info	The Instance card: the database’s health and its status with the reason first, then its version, its collectors, when it started, when data last arrived, its TLS, and its replication, with a replica’s lag behind its source. Beside it, the Layers available card: each of the seven monitoring layers and its state, L5 Query analytics with a statement-load sparkline. Below them, the Connection card, with Accept new key (shown only while a collector reports another key) and Edit setup; the Storage ceiling card beside it; on RDS and Aurora the Cloud metrics card, with each collector’s check, Test again and the read policy, and under it the Instance (from the RDS API) and Collection cards (see Where you see them); the Logs card, with each log’s setting, who reads it, its state and fix, and its last report, and Test again (see The Info tab’s Logs card); the database’s tags, with Save tags; and Delete this database
Audit	The database’s audit trail

The actions on Collectors and Info need database.edit, and Delete needs database.delete; everyone else reads both tabs. Everyone who can view the database reads its Alarms and Incidents tabs too. Health is not shown while the database is paused. A draft shows only Overview and Audit: Overview says Connection not configured, with Continue setup.

The Overview

The Overview has two cards. The first is compact: Now on the left and Data coverage, 30 days on the right, about a quarter of the card’s width, with a line between them. On a narrow screen, Data coverage sits under Now.

Part	Shows
Now	as of the time of the newest sample in the last hour, or no recent sample, and five gauges: Connections, as a share of max_connections with N of the maximum beside it; Threads running; Queries per second; Buffer pool hit ratio; and Monitoring coverage. They refresh every minute.
Data coverage, 30 days	The share of the last 30 days’ expected minutes that hold data, and the 30-day strip of its gaps. Hover over the strip, or over a band on it, for what it shows. See Gaps and the coverage record.

The second card, Telemetry, holds the charts. On RDS and Aurora, beside its title, Performance | Capacity switches between its two views, as on a server’s Overview; elsewhere it shows the Performance charts alone. The page opens on Performance, and the address keeps the view, so a reload or a shared link opens the view it shows. Its one time range picker, at the top, sets the range for both views, and the database’s Queries, Logs and Incidents tabs follow the same range. While the range is relative, the charts of the view shown refresh every minute.

• Performance: the workload charts, four to a row. They shade the gaps in the data, and a thin line along the bottom marks data a collector delivered late; hover over either for its cause, window and length.
• Capacity, on RDS and Aurora only, never on an RDS Proxy endpoint or a database outside AWS: the Read policy when the collector’s role needs it, and the Host metrics (CloudWatch) charts. When the data is not being collected — no permission, no instance role, throttled and so on — the view opens with the state’s full message and what to do, such as No CloudWatch metrics: the collector’s role was refused … or Waiting for the collector’s first match. See The Capacity view.

The database’s Instance, Layers available, Instance (from the RDS API) and Collection cards and its tags are on Info; its storage, schema changes and advisor findings are on their own tabs, and its open incidents on Incidents.

Monitoring coverage

The Monitoring coverage gauge is the share of the monitoring layers that apply to this database and are collected. The Layers available card on the Info tab lists the same seven layers, each with its state:

Layer	What it collects
L1 Availability and health	Up or down and why, and restarts
L2 Workload	The workload: the Overview’s Performance charts
L3 Sizes and growth	Storage and growth
L4 Schema-change history	Schema-change history
L5 Query analytics	Query analytics
L6 Advisor	Advisor
L7 Cloud metrics (CloudWatch)	Cloud metrics for RDS and Aurora

Every layer that applies weighs the same:

A layer that is	Counts
Collected	1
Partial	half
Not collected	0
Not applicable	Not counted at all

• Partial, for example: L3 collected without row estimates (it needs tier C); L4 on InnoDB tables only, or recording tables only (see The limits); L5 over the digest limit; L6 partial; L7 with only rds:DescribeDBClusters denied, or while AWS throttles it.
• Not collected includes L4 before its first pass, and above the table limit, where schema history is off.
• Not applicable: L7 anywhere but RDS and Aurora, a self-managed database included, and on an RDS Proxy endpoint, which has no CloudWatch metrics of its own.

The gauge reads N%, with of N layers beside it, and — with no probe yet until the active collector’s first probe has reported what the database allows. It is green at 100 %, amber below 100 % and red at 50 % or less. For example, a self-managed database with every grant but performance_schema off collects L1 to L4, none of L5 and half of L6 (the advisor’s statement checks need performance_schema), and L7 does not apply: 4.5 of 6 layers, 75%.

Hover over the gauge for the detail. Its first line reads, for example, 4.5 of 6 monitoring layers collected. A partial layer counts half; a layer that cannot apply to this database is not counted. Then one row per layer, with its verdict: Collected, Partial (counts half) — and why, Not collected — and why, or Not counted — Not applicable: and why.

Collector pools

A database is collected by one of your servers, chosen from a pool: specific servers in your order of preference, or every server carrying a set of tags (all of some tags, any of others). A server that gets the tags later joins the pool on its own; one that loses them leaves it.

Only the servers on the Active view of Servers can be collectors. An archived or deleted server leaves every pool and is no longer shown on the Collectors tab or in the Collectors step, and a pool of specific servers cannot name an archived one. Reactivate a server to bring it back into a pool.

WatchTower15 picks one active collector and keeps another as a warm standby: your order first (for specific servers), then the fewest databases carried. If the active collector stops — powered off, replaced, its agent stopped, or it cannot reach the database while the standby can — the standby takes over on its own. A server that shuts down cleanly says so, and hands over in under a minute; one that vanishes hands over about three minutes later, once its heartbeat is 90 seconds old. The Collectors tab shows each pool member’s role and last probe (a member that cannot collect reads Not collecting, with the reason and when it was last heard from), and the database’s Audit tab records every change of collector.

A collector cut off from WatchTower15 keeps collecting and keeps the data on its own disk (for up to 72 hours). When it reconnects, it delivers what it collected up to the moment a collector was next chosen, another server or itself again; what it collected after another collector took over, or while the database was paused, is discarded. A self-managed database’s slow and error logs are not part of this: its host server reads and sends them whatever its role in the pool.

A server can collect a database when it is approved and active, its agent can collect databases (it upgrades itself within minutes of a release), it has sent a heartbeat in the last 90 seconds and it carries fewer than 20 databases. A pool of one never fails over. While its one server is cut off, the database is Awaiting collector, a No collector gap on its coverage; once that server reconnects, it delivers what it kept meanwhile, and the gap fills in.

Servers that get replaced

In an Auto Scaling group, use a tag rule for the pool and a credential source that survives replacement — AWS Secrets Manager, SSM Parameter Store or RDS IAM — or write the credentials file from your provisioning. A file written by hand on one server is gone when that server is replaced.

The grant script

Step 4 generates a script for your engine, version, connection and authentication. Run it on the database as an administrator. It creates the user wt15_monitor with:

• REQUIRE SSL on every TCP connection, and at most three connections;
• a host part that is your collectors’ subnet, never one server’s address — a replacement server gets a new one;
• tier A (PROCESS, REPLICATION CLIENT): health, workload, the storage sizes, and the advisor’s checks on tables and indexes;
• tier C (SELECT on InnoDB’s statistics tables): row estimates, the sizes of tables kept in a shared tablespace, and the size of each unused index the advisor reports;
• tier D (REFERENCES, SHOW VIEW, and SHOW_ROUTINE on MySQL 8): the full schema-change history — exact column types, views, non-InnoDB tables and, with SHOW_ROUTINE, routines;
• tier B (SELECT on performance_schema.events_statements_summary_by_digest): query analytics, which also needs performance_schema on. Its SELECT on performance_schema.table_io_waits_summary_by_index_usage gives the advisor its unused indexes. The script’s other performance_schema grants are not read yet: grant them now, so you grant once;
• the optional account grant (SELECT on six named columns of mysql.user, never a password hash), last and marked optional: the advisor’s account check. Run it only if you want that check.

View definitions are out of scope: no grant in the script reveals them, and Verify reports them as not available (expected). A user holding more than monitoring needs — a global SELECT, a write privilege, SUPER or ALL — is flagged Over-privileged on the database’s page.

Privacy mode and the redaction key

Mode	What reaches WatchTower15
Hashed (default)	Names — databases, tables, indexes — only as a keyed hash. The key never leaves your estate. No statement text.
Clear names	Names in clear, so findings can name the table; normalised statement text (literals replaced by ?) on the Queries tab.
Counts only	Numbers only.

Counts only still keeps a database’s schema history: each pass records how many tables, columns, indexes, views and routines changed, not which. The per-object history recorded before the switch is kept. See Names and revealing a key. Counts only also keeps a database’s statement load and latency, but sends no per-statement figures: its Queries tab shows the charts alone. See Names, keys and revealing a key. The Advisor’s checks on tables, indexes and accounts report a count in Counts only, never which objects, and its checks on statements are not evaluated. See Names, keys and revealing a key.

Every database has one redaction key, which you generate once (openssl rand -hex 32) and give to every collector of that database. WatchTower15 never sees it: each collector reports the key’s fingerprint, and Verify shows a missing key or a mismatch.

In Hashed mode the Storage & growth tab shows each schema and table as its key, such as #3f9a1c…, the Queries tab each statement, and the Advisor tab each table, index, statement and account. To see the name behind a key, click it: Reveal on the host gives the db reveal command to run on one of the database’s collectors. It hashes the database’s current names, or its statements, with the redaction key on that server, prints the match, and sends nothing to WatchTower15. See Revealing a key on your host and, for statements, Revealing a key; for indexes and accounts, the Advisor’s.

A collector reporting another fingerprint shows Key mismatch and is not eligible to collect. Either give it the database’s key, or — when you replaced the key on purpose — press Accept new key on the Info tab’s Connection card. The new fingerprint becomes the reference, and the change is recorded on the database’s Audit tab. The advisor’s findings about tables, indexes, statements and accounts are deleted and return, under the new keys, with the next facts pass: their dismissals are lost.

Storage and growth

Each database’s Storage & growth tab shows its size by kind, schema and table, its growth per day with a forecast at 30, 90, 180 and 365 days, and days to full: when it reaches its ceiling. The ceiling is the data volume for a self-managed database. For RDS it is the storage AWS reports once your collectors read cloud metrics, or else the storage ceiling you enter on the Info tab; Aurora has none. The Databases list adds Size and 30-day growth columns, and the Info tab’s layers card shows it as L3 Sizes and growth. See Storage and growth.

The table limit

WatchTower15 reads the storage of a database with up to 2,048 tables by default. Above that, no storage size is read for that database, so it has no growth forecast and no days to full, and its Storage & growth tab says Over the table limit. Its schema history is off too. Its health, performance and other alarms carry on. The limit applies to each database on its own; to raise it, contact support, up to 4,096 tables. See The table limit.

Schema-change history

Each database’s Schema changes tab lists every table, column, index, view and routine created, altered, renamed or dropped, pass by pass: every 6 hours, and on Refresh now. The agent compares the schema on your own host and sends only the changes, as keyed hashes unless the database is in Clear names mode. The Info tab’s layers card shows it as L4 Schema-change history. See Schema-change history.

Query analytics

Each database’s Queries tab shows which statements cost it the most — by an Impact Index, total time, calls, average time, rows examined, no-index use or errors, highest or lowest first — over any window in the last 30 days, with its statement load and average latency. Every 5 minutes the agent on the active collector reads MySQL’s statement summary from performance_schema and sends the leading statements’ figures, each under a keyed hash; their normalised text only in Clear names mode. It needs performance_schema on — on RDS and Aurora, a custom parameter group and a reboot — and tier B. The Info tab’s layers card shows it as L5 Query analytics. Statement statistics expire after 30 days. See Query analytics.

Advisor

Each database’s Advisor tab lists findings about its configuration, schema, workload and hardening — tables without a primary key, redundant and unused indexes, statements that run without an index, a buffer pool too small for the data, a TLS certificate about to expire — from 21 checks in four groups. Each finding gives its evidence, a recommendation and a link to its check’s section, and can be dismissed with a reason. Once a day, at about 04:00 on the collector’s clock, and on Run now, the agent on the active collector reads a small set of facts — InnoDB’s catalogue, index usage and, with the optional account grant, six columns of mysql.user — and sends them as keyed hashes; WatchTower15 runs the checks on them within about 5 minutes. WatchTower15 never changes your database, and findings are not alarms: they send no notification. The Info tab’s layers card shows it as L6 Advisor, and the tab’s header counts the open findings by severity. See Advisor.

Cloud metrics (RDS and Aurora)

On an RDS or Aurora database, the Overview’s Capacity view shows what the engine cannot see: the host’s CPU, freeable memory and swap, free storage against allocated, IOPS, latency, throughput, queue depth, burst and credit balances, replica lag, connections and, with Performance Insights on, database load. The agent on the active collector reads them from CloudWatch every 5 minutes and the instance’s facts from the RDS API every hour, with the collector’s own instance role. Attaching the read policy to that role is how you turn it on: eight read actions in two statements, six for cloud metrics and two that read the instance’s slow and error logs. AWS bills about $1.23 to $1.84 a month per database to your account. The Info tab’s layers card shows them as L7 Cloud metrics (CloudWatch), and RDS’s own storage figures become its storage ceiling. See Cloud metrics for RDS and Aurora.

Slow and error logs

Each database’s Logs tab shows its slow query log and its error log: the window’s slow statements and error-log errors at its head, then each log’s histogram and lines, with filters, grouping by statement and links to the Queries tab. On a self-managed database the agent on its host server reads the log files; on RDS and Aurora the active collector reads them through the RDS API, with the read policy’s two log actions. Each record is parsed on that server: only keys, numbers and codes leave it, with normalised statements, scrubbed messages and account names only in Clear names mode. The slow log must be on, which is your choice: WatchTower15 never changes it. Storms are summarised beyond 600 slow statements and 300 error-log lines a minute. The logs are included in the database’s price, and never count toward your log usage. The Info tab’s Logs card shows each log’s state and its fix. See Slow and error logs.

Alarms

Every database gets sixteen alarms, routed through your policies and channels:

Alarm	Fires when	Default
Database unreachable	The collector gets no answer (the reason is shown)	warning after 2 minutes, critical after 5
No collector reporting	No report arrives from any collector	critical after 5 minutes
Database restarted	The server restarted (a failover to another server is not a restart)	warning, within 10 minutes
Database connections high	Open connections against max_connections	warning 80 %, critical 95 %
Database threads running high	Threads running a statement	warning 32, critical 64
Database replication stopped	A replica’s IO or SQL thread stops	critical
Database replication lag high	A replica falls behind its source	warning 60 s, critical 300 s
Database aborted connections high	Failed connection attempts	warning 1/s, critical 5/s
Database slow queries high	Statements slower than long_query_time	warning 1/s, critical 5/s
Database deadlocks	InnoDB reports a deadlock	warning
Database storage filling up	Its storage is projected to reach its ceiling at its current growth	warning 30 days, critical 7
Database schema changed	A schema pass finds a table, column, index, view or routine created, altered, renamed or dropped	warning; resolves itself after 15 minutes, without a resolve notification
Database error-log errors	The error log records an [ERROR] line or a crash in the last 5 minutes; warnings and notes never fire it	warning
RDS free storage low	The free share of the RDS instance’s allocated storage, from cloud metrics	warning 20 %, critical 10 %
RDS CPU high	The CPU of the RDS or Aurora host, averaged over 10 minutes, from cloud metrics	warning 80 %, critical 95 %
RDS storage burst balance low	The gp2 storage’s I/O burst credits left, from cloud metrics	warning 20 %, critical 10 %

The database’s Alarms tab shows each alarm as a tile, as a server’s page does: its live value on a gauge, or its state in words, refreshed every minute while the tab is open, with its state, its conditions and its policies. The tiles sit under Availability, Connections, Queries, Host, Replication, Storage, Schema and Logs. The filters are All, Firing, Critical, Warning, OK, Inactive, No policy, Default and Custom; Firing is selected when you open the tab if anything is firing. A switched-off alarm reads Off, and so does every alarm of a paused database, with the reason under it. The database’s open incidents are on its Incidents tab. See A database’s alarms.

Anyone who can view the database (database.view) can read its alarms there. With alarms.edit you can add alarms (Add alarm) and edit them, and from a tile’s menu Duplicate, Disable or Enable them; Delete needs alarms.delete. Policies are named for holders of policies.view. The Incidents tab needs only database.view too: see A database’s incidents. Thresholds and how long a condition must last can be tuned per database, like any alarm’s — see Tuning an alarm.

• A database with no collector shows Awaiting collector: it raises no alarm until it has reported once. That also holds after Resume, if every collector was decommissioned during the pause.
• A database that is not a replica, and every Aurora cluster, has no replication series, so the replication alarms never fire there. MySQL 5.7 does not count deadlocks where the agent can read them, so the deadlock alarm never fires on 5.7.
• No collector reporting stays quiet during a WatchTower15 outage, and collectors are not reassigned on their own during one, nor in the two minutes after it (Reassign now still works).
• Database storage filling up is quiet until 7 days of history exist, and is never evaluated on Aurora or on an RDS database with no storage ceiling reported by AWS or entered. A full database stays critical, even once its growth has stopped, until space is freed or the ceiling is raised. Removing the ceiling, or deleting the server a self-managed database runs on, resolves an open incident at once, without a notification. See The storage alarm.
• Database schema changed is quiet until the first change. A first pass, a new redaction key, a change of layer, an engine upgrade, and a routine privilege granted or revoked record a new baseline silently and never raise it. See The alarm.
• The three RDS alarms are listed on every database, and never evaluated where there is no RDS series: on a self-managed database, or where your collectors’ role does not carry the read policy. Aurora has no allocated storage, so RDS free storage low never fires there, and only gp2 storage has burst credits. Their points are up to about 8 minutes old. See The three RDS alarms.
• Database error-log errors is evaluated only while the error log is read: its tile reads No data until then. On RDS and Aurora it is up to about 6 minutes late, and an incident already open stays open while the log’s reader is stopped. See The alarm.
• The Advisor’s findings are not alarms: they open no incident and send no notification. See Findings are not alarms.

Gaps and the coverage record

The database’s Overview shows its data coverage over 30 days in Data coverage, 30 days, the right-hand part of its first card: the share of the expected minutes that hold data, and a 30-day strip, green where data is held, with each gap or outage a coloured band on it.

• Hover over a band for its cause, when it started and ended, how long it lasted, and what the cause means.
• Hover over the green for the share, the dates the 30 days run from and to, and what the share leaves out: Paused and No collector are left out of the share: neither is the database’s fault, nor WatchTower15’s.

The Overview’s Performance charts shade the same gaps, in the strip’s colours. Hover over a gap, on the strip or on a chart, for its cause, window and length, and what the cause means. The causes:

Gap	Means
Database unreachable	The collector reported the database down: data, not a gap.
Collector handover	From the old collector’s last sample to the new one’s first.
WatchTower15 outage — not your database	A recorded WatchTower15 outage overlaps the gap.
Catching up	The collector is still delivering data it kept during the gap.
Rejected by WatchTower15	WatchTower15 refused the collector’s data: its clock or its credentials.
No connection from the collector	The collector ran but could not reach WatchTower15.
Collector host down	The collector’s server was down.
Collector agent not running	The agent on the collector was stopped.
No report from the collector	None of the above: the collector was silent, or could not reach WatchTower15.
Paused	Paused by you.
No collector	No eligible collector in the pool.
Delivered late (a marker, not a gap)	The collector kept this data and delivered it after the gap: the data is there. A thin line under the strip and along the bottom of each Performance chart; hover over it for its window and length, and what it means.

A collector that cannot reach WatchTower15 keeps its data for up to 72 hours, and delivers it when it reconnects: the gap then fills in, and Delivered late marks where. While the data is on its way, the gap reads Catching up, except across a change of collector, which reads Collector handover until the data lands, and in a stretch with no collector, which reads No collector until then. What the collector could not keep stays a gap, with its cause.

Paused and No collector do not lower the coverage share: neither is the database’s fault, nor WatchTower15’s. Data a collector delivers late from a No collector stretch counts as covered, and carries the Delivered late line instead.

Pooled endpoints

Point the collectors at one server: an instance endpoint, or a cluster’s writer endpoint. An endpoint that spreads connections across several servers — an RDS Proxy, an Aurora reader or custom endpoint, a pooler or a load balancer — mixes their counters. WatchTower15 warns about such a host name in the setup, and when the collector sees the server behind the endpoint change between connections, the database shows This endpoint mixes several servers until it settles. For an RDS Proxy, once your collectors read cloud metrics, the page lists the instances behind it, each with Add as a database.

Pausing, deleting, billing

Pause (Collectors tab) stops collection, alarms and billing until you Resume. Delete (Info tab) removes the database’s history, incidents and alarms, its schema and table lists, its schema-change history, its statement list and statement text, its advisor facts and findings, and its log messages and account names, from WatchTower15; the database itself is untouched. Its statement statistics expire 30 days after they were collected (see Erasure), and its log events 30 days after they were recorded (see Retention and erasure).

A database is one billable resource, billed per hour in which a collector reported it, at the same rate as a server. Draft and paused hours are never billed, even when a collector delivers data from a paused hour late. An hour with no collector is billed only when the last collector, cut off from WatchTower15 at the time, delivers data it kept from that hour. Data a collector delivers late bills the hour it was collected in, unless that hour began before your latest invoice was issued, or before the database’s first live report reached WatchTower15.

Permissions

database.view reads databases; database.edit adds them and changes their setup; database.delete deletes them. See Roles & permissions.

To watch databases beside everything else, add the database widgets to a dashboard.