Skip to main content
Card class: Hero • Category: Executive Overview

​
At a glance

The MariaDB Health Score is a single 0 to 100 composite that rolls up the instance’s most important operational signals (connection-pool saturation, query latency, error rate, replication lag, buffer-pool hit rate, disk usage, and Galera quorum where present) into one number a platform lead can read at a glance. It answers “is the database fundamentally healthy right now, and was it healthy over the last week?” A score of 100 means every input is inside its green band. A score below 70 means at least one critical input has degraded enough to warrant attention before it becomes an incident.
What it tracksA weighted composite health index for the MariaDB instance (or Galera cluster) for the selected period. The score blends the sub-metrics that each have their own card, so a drop here always traces back to a specific input.
Data sourceDerived inside Vortex IQ from the same SHOW GLOBAL STATUS, information_schema, and Galera wsrep_* counters that feed the underlying cards. No separate query: it reuses the polled inputs.
Time windowRT/7D. The gauge shows the live composite; the trend shows the rolling 7-day band so you can tell “always been like this” from “degraded this week”.
Alert trigger<70. A composite below 70 flags amber on the Executive Overview and pages the on-call rota if sustained.
Calculation basisWeighted average of normalised sub-scores. Each input is mapped to a 0 to 100 band against its own threshold (for example pool saturation 0% maps to 100, 90%+ maps to 0), then combined by weight.
SensitivityThis is a sensitivity card: the thresholds and input weights are tunable per profile in the Sensitivity tab so the score reflects your own baseline rather than a generic default.
What does NOT move itCosmetic or non-operational counters (uptime in days, total queries served lifetime) are excluded; they do not indicate health.
Rolesowner, engineering, operations

​
Calculation

The score is a weighted blend of the instance’s critical operational inputs, each first normalised to a 0 to 100 sub-score against its own threshold, then averaged by weight. The inputs and the direction that hurts the score are:
Input (sibling card)Source signalDirection that lowers the score
Connection pool saturationThreads_connected / max_connectionsSaturation rising toward 90%+
Query error rate(Aborted_clients + Connection_errors) / QuestionsError rate above 1%
Query latency p95 / p99statement digests in performance_schemap95 above 200ms, p99 above 500ms
Buffer-pool hit rateInnodb_buffer_pool_read_requests vs ..._readsHit rate below 95%
Replication lagSeconds_Behind_Master / wsrep_local_recv_queueLag above 10s
Disk usagedata directory free spaceUsage above 90%
Galera quorum (clustered only)wsrep_cluster_status, wsrep_cluster_sizeStatus not Primary, or node count below expected
Each sub-score sits at 100 when the input is comfortably inside its green band and falls toward 0 as the input crosses its alert threshold. The composite is the weighted mean, so one badly degraded critical input (a non-Primary Galera state, for example) can pull the headline well below 70 even when everything else is green. Because every input has its own card, a low score is always explainable: open the Executive Overview, find the red sub-metric, and drill into its card. Calculated automatically from your MariaDB data; see the worked example for a typical reading.

​
Worked example

A platform team runs a 3-node Galera cluster behind a high-traffic Magento storefront. Snapshot taken on 14 Apr 26 at 19:40 BST during an evening promotional push.
InputReadingSub-scoreWeight
Connection pool saturation78% (climbing)55high
Query error rate0.3%92high
Query latency p95240ms (over 200ms band)60medium
Buffer-pool hit rate99.1%100medium
Replication / Galera lagflow control paused 2%90high
Disk usage71%100medium
Galera quorumPrimary, size 3/3100critical
The composite lands at 74, amber but not yet alerting. The headline gauge sits just above the 70 line and the 7-day trend shows the score has slipped from a steady 88 over the past three hours. The platform lead reads three things:
  1. The slip is real, not noise. The 7-day band makes clear this instance normally runs at 88, so a drop to 74 during the promo is a genuine degradation, not the usual evening shape.
  2. Two inputs are dragging the score. Pool saturation (55) and p95 latency (60) are the culprits; everything else is green. The story is “traffic is pushing the connection pool and queries are starting to queue”, a classic load-driven pattern rather than a fault.
  3. Action is preventative, not reactive. Because the score is still above 70, the team has runway: raise max_connections headroom or add a read replica before saturation crosses 90 and the cluster starts refusing connections at checkout.
Composite framing for this snapshot:
  - Live score: 74 (amber, threshold <70)
  - 7-day baseline: 88
  - Largest drags: pool saturation 55, p95 latency 60
  - Recommended action: add read capacity before saturation hits 90%
  - If ignored: saturation crosses 90% -> "Too many connections" at checkout -> revenue impact
Three takeaways:
  1. A composite is a starting point, never an endpoint. The number tells you “look”, the sub-metric cards tell you “where”. Always drill from the score into the red input before acting.
  2. Read the gauge with the 7-day trend. A score of 74 means very different things for an instance that normally runs at 75 versus one that normally runs at 92. The trend supplies the baseline.
  3. One critical input can dominate. A non-Primary Galera state or a disk above 90% can sink the headline on its own regardless of how green the rest is, by design, because those conditions are existential for the database.

​
Sibling cards

CardWhy pair it with MariaDB Health ScoreWhat the combination tells you
Connection Pool Saturation %Highest-weight load input into the composite.A low score during a traffic peak almost always traces to rising saturation here.
Query Error Rate %Error-side input.Score down plus error rate up equals a fault, not just load; investigate failing statements.
Query Latency p95 (ms)Latency input.Score down plus p95 up equals queries queueing; check slow-query rate and buffer pool.
InnoDB / XtraDB Buffer Pool Hit Rate %Memory-efficiency input.A falling hit rate drags latency and the composite together; often a sizing problem.
Async Replication Lag (seconds)Replication input.Lag spikes pull the composite down and threaten read-after-write consistency.
Database Disk Usage %Capacity input with hard ceiling.Disk above 90% can sink the score alone; a full disk halts writes entirely.
Galera Cluster StatusExistential quorum input on clustered instances.A non-Primary status collapses the composite because the cluster has gone read-only.
Queries per Second (live)Load context (not a direct input).Read the score against QPS to separate “healthy under load” from “unhealthy at rest”.

​
Reconciling against the source

Where to look on the server: There is no single native command that emits a “health score”: it is a Vortex IQ composite. To reconcile, verify each input independently against MariaDB’s own tooling, then confirm the headline moves in step.
SHOW GLOBAL STATUS; for the raw counters (Threads_connected, Aborted_clients, Connection_errors_%, Innodb_buffer_pool_read_requests, Innodb_buffer_pool_reads). SHOW VARIABLES LIKE 'max_connections'; to confirm the saturation denominator. SHOW ALL SLAVES STATUS\G (or SHOW REPLICA STATUS\G on newer builds) for replication lag. SHOW STATUS LIKE 'wsrep_%'; for Galera quorum and flow-control inputs. SELECT DIGEST_TEXT, AVG_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC; for the latency inputs.
Why our number may legitimately differ from a hand calculation:
ReasonDirectionWhy
Profile weightsVariableThe composite uses your configured input weights; a manual unweighted average will differ.
Normalisation curvesVariableEach input is mapped through a band curve, not a linear scale; the midpoint is not 50 for every input.
Poll timingBriefThe composite reuses the last polled value of each input; a sub-metric sampled seconds later can shift the score marginally.
Galera presenceStructuralOn a non-clustered instance the Galera inputs are dropped and weights re-normalise across the remaining inputs.
Managed-service note: On Amazon RDS / Aurora, Azure Database for MariaDB, or MariaDB SkySQL the provider exposes the same underlying counters (DatabaseConnections, ReplicaLag, CPU and memory) as console metrics. There is no native composite to compare against; reconcile input by input.

​
Known limitations / FAQs

Why is my health score 74 when every alert is green? The composite turns amber before individual cards cross their hard alert thresholds. A 74 means one or more inputs are in the warning zone (for example pool saturation at 78%, below the 90% alert but well off the green band). That is the point of the score: it gives you runway to act before a sub-metric trips its own alert. The score dropped but I cannot tell which input caused it. Open the Executive Overview and scan the sub-metric cards for the one in amber or red. The composite is always explainable from its inputs; if two inputs moved together (latency and buffer-pool hit rate, say) they usually share a root cause. Use Vortex Mind to trace the upstream cause. Can I change which inputs count and how much they weigh? Yes. This is a sensitivity card. In the Sensitivity tab you can adjust each input’s weight and its threshold band per profile. Teams that run read-heavy reporting replicas often raise the buffer-pool and latency weights; teams on Galera raise the quorum weight to make a non-Primary state dominate. My instance is a single node with no replication or Galera. Does the score still work? Yes. Replication and Galera inputs are dropped and the weights re-normalise across the remaining inputs (saturation, errors, latency, buffer pool, disk). The score is then a clean read on a standalone server. Why does the score sometimes sit at 100 for days then drop sharply? A healthy instance inside every green band scores 100 and stays there until an input crosses into its warning zone. The drop is sharp because crossing a threshold moves that input’s sub-score quickly through the band curve. The 7-day trend makes these step changes easy to spot. Should I page on a score of 69? The <70 trigger is the default amber boundary, not an automatic page. Whether 69 pages depends on your sustained-duration setting in the Sensitivity tab. A momentary dip to 69 during a deploy is normal; a score parked below 70 for several poll cycles is worth waking someone for. Tune the sustained window to your tolerance. Does a high score guarantee there is no problem? No. The score only reflects the inputs it measures. A logical fault (a bad migration, a corrupt index, a runaway report query that has not yet pushed latency past its band) can exist at a score of 95. Treat the score as a strong negative signal (low score means definitely investigate) rather than an absolute all-clear.

​
Tracked live in Vortex IQ Nerve Centre

MariaDB Health Score is one of hundreds of KPI pulses Vortex IQ tracks across MariaDB and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.