At a glance
How long the MySQL server process has been running continuously since its last start or restart, shown in real time. A high, steadily climbing value is the healthy norm; a sudden reset to near zero means the instance restarted, which for a production database is almost always worth knowing about because it flushes the in-memory buffer pool and drops every open connection.
What it tracks
The card reads theUptime global status variable, the count of seconds since mysqld started, and renders it as a human-readable duration (for example, 14 days 6 hours). It is a live (RT) reading sampled on each refresh.
Uptime is most useful as a change detector rather than as a target. An unexpected reset signals an OOM-kill, a crash, a failover, or a planned maintenance restart. After any restart the InnoDB buffer pool starts cold, so query latency runs higher until the working set is paged back into memory; pair this card with InnoDB Buffer Pool Hit Rate to see that warm-up. On managed services that perform planned maintenance or auto-failover, uptime resets are expected and benign, but they still explain a transient latency or hit-rate dip. Very long uptimes are not automatically a virtue either: an instance up for 400 days may be overdue a patch cycle for security fixes.
Reconciling against the source
Confirm directly withSHOW GLOBAL STATUS LIKE 'Uptime'; (value in seconds) or SHOW STATUS LIKE 'Uptime_since_flush_status'; for time since the last counter flush. On managed services check the instance event log (RDS / Aurora events, Cloud SQL operations log) for restart and failover events that explain a reset.