> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Supabase Health Score, Supabase > Supabase Health Score for Supabase projects. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Executive Overview](/nerve-centre/connectors#connectors-by-type) ## At a glance > A single 0 to 100 composite that rolls the project's most important capacity, performance, error and durability signals into one number a platform lead can glance at. It answers "is my Supabase project broadly healthy right now, or is something pulling it down?" without forcing anyone to read a dozen gauges. The score is deliberately conservative: any one component in the red drags the whole number down, so a low score always means at least one real problem, never a statistical artefact. Below 70 the project has a material issue that warrants someone looking now. | | | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it tracks** | A weighted composite of the project's capacity, performance, error-rate and durability signals, normalised to a 0 to 100 score. | | **Data source** | `detail`: Supabase Health Score for the selected period. Computed by the Vortex IQ Supabase connector from the underlying component cards (cache hit rate, pool saturation, disk usage, query error rate, latency, backup age and replication lag). | | **Calculation basis** | Each component is scored 0 to 100 against its own healthy band, then blended; the weakest components are weighted to pull the headline down (worst-of bias), so the composite cannot look healthy while a sub-signal is red. | | **Time window** | `RT/7D`: a live score plus a 7-day trend line so you can see whether health is improving or eroding, not just today's value. | | **Alert trigger** | `< 70`. Below 70 at least one major component is in its red band and the project needs attention. | | **Chart type** | Gauge (0 to 100), green 85+, amber 70 to 85, red below 70. | | **Roles** | owner, engineering, operations (DBA / platform / SRE) | ## Calculation The health score is a roll-up, not a primary measurement. The connector collects each component card's current reading, scores it 0 to 100 against that metric's own healthy band, then combines the component scores into the headline. The components and the direction that hurts the score: | Component | Healthy | Hurts the score when | | ------------------------------------ | ------------ | -------------------- | | Buffer cache hit rate | 99%+ | drops below 95% | | Supavisor pool saturation | below 70% | climbs above 90% | | Database disk usage | below 75% | climbs above 90% | | Database query error rate | below 0.1% | climbs above 1% | | Postgres query latency p95 | below 100 ms | climbs above 200 ms | | Last backup age | below 24 h | climbs above 72 h | | Read replica lag (if replicas exist) | below 1 s | climbs above 10 s | The blend is intentionally biased toward the worst component rather than a flat average. A flat mean would let four green signals mask one red one, producing a comfortable-looking 80 while the project is actually losing data or refusing connections. Instead, the weakest component disproportionately pulls the headline down, so a red sub-signal cannot hide. This is why the score can sit at 62 even when six of seven components are healthy: the seventh (say, disk usage at 94%) is a genuine, imminent problem. Because it is a composite, the score does not tell you *what* is wrong on its own; it tells you *that* something is wrong and how severe. The fix is always to open the component cards listed under Sibling cards and find the one in the red. ## Worked example A platform team owns a Supabase Pro project behind a retail storefront. The health score reading is taken on 22 Apr 26 at 14:05 BST during an afternoon promotion. The headline reads **64** (red), down from a 7-day baseline of 91. Opening the component breakdown: | Component | Reading | Component score | Band | | ------------------------- | ------- | --------------- | ------- | | Buffer cache hit rate | 98.9% | 96 | green | | Supavisor pool saturation | 93% | 28 | **red** | | Database disk usage | 71% | 88 | green | | Query error rate | 0.4% | 78 | amber | | Query latency p95 | 145 ms | 71 | amber | | Last backup age | 9 h | 99 | green | | Read replica lag | 0.6 s | 98 | green | The story is immediate: pool saturation at 93% is the dominant drag. The promotion has driven a traffic burst, the Supavisor pool is nearly exhausted on the Pro tier's connection cap, and the queued connections are also nudging the error rate and p95 into amber. The composite of 64 reflects the worst-of bias: one red component plus two ambers is enough to drop the headline 27 points below baseline. ```text theme={null} What the platform lead does next: 1. Open Supavisor Pool Saturation % -> confirm 93% and rising. 2. Check whether the burst is real traffic or clients bypassing the pooler. - If real: raise the pool size or size up compute for the promo window. - If bypass: fix the client to route through the transaction pooler (port 6543). 3. Re-check the score in 10 minutes; expect it to climb back toward 85+ as saturation falls and the error / latency ambers clear. ``` Three takeaways a platform team should remember: 1. **The score is a starting point, not a diagnosis.** A 64 tells you to act and how urgently; the component breakdown tells you *what* to fix. Never act on the composite alone. 2. **One red beats four greens.** The worst-of bias is the point. If the score were a flat average, this project would have read 80 and nobody would have looked, while the pool quietly ran out of connections. 3. **Watch the 7-day trend, not just the live value.** A score of 78 that has been falling 2 points a day for a week is a slow leak (often disk creeping up or a connection leak); a 78 that dropped from 91 an hour ago is an acute event. The trend line distinguishes the two. ## Sibling cards | Card | Why pair it with Supabase Health Score | What the combination tells you | | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | [Supavisor Pool Saturation %](/nerve-centre/kpi-cards/supabase/supavisor-pool-saturation) | A frequent dominant drag on the score. | A red score with high saturation means a connection-capacity event, usually a burst or a pooler bypass. | | [Database Disk Usage %](/nerve-centre/kpi-cards/supabase/database-disk-usage) | The component that triggers read-only mode at the cap. | A slowly falling score plus rising disk equals a durability risk, not a load spike. | | [Buffer Cache Hit Rate %](/nerve-centre/kpi-cards/supabase/buffer-cache-hit-rate) | Memory-pressure component. | Cache dropping below 95% explains a latency-driven score drop. | | [Database Query Error Rate %](/nerve-centre/kpi-cards/supabase/database-query-error-rate) | The error component. | A score drop driven by errors points at failing statements, not capacity. | | [Database Queries per Second (live)](/nerve-centre/kpi-cards/supabase/database-queries-per-second-live) | Load context for the whole score. | A score drop at a QPS spike is load-driven and often self-resolves; a drop at flat QPS is structural. | | [Last Backup Age (hours)](/nerve-centre/kpi-cards/supabase/last-backup-age-hours) | The durability component. | A stale backup quietly caps the score even when everything else is green. | | [Project Uptime](/nerve-centre/kpi-cards/supabase/project-uptime) | Availability context. | Score red plus uptime intact equals "degraded, not down". | ## Reconciling against the source **Where to confirm this in Supabase's own tooling:** > Supabase has no single "health score" of its own, so the way to reconcile this card is to verify each component against native tooling: > **Supabase Studio → Reports → Database** charts cache hit rate, connections, disk and query latency. > **`pg_stat_database`** and **`pg_stat_activity`** in the SQL Editor confirm cache hit rate, error counts and connection counts. > **Project Settings → Database → Backups** shows the most recent backup timestamp and PITR window. > **Supabase status page** confirms whether any platform-wide incident is contributing. **Why our number may legitimately differ from a manual tally:** | Reason | Direction | Why | | ------------------------------ | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Worst-of weighting** | Composite lower than a naive average | The blend is biased toward the weakest component on purpose, so a single red sub-signal pulls it down further than a flat mean would. | | **Component sampling windows** | Slight lag | Each component has its own window (`RT`, `5m`, `1h`); the composite reflects the most recent sample of each, so a just-resolved red may still be visible for one cycle. | | **Replica component skipped** | Score relatively higher | If the project has no read replicas, the replication-lag component is omitted rather than scored zero, so a single-instance project is not penalised for lacking a paid feature. | | **Threshold customisation** | Either direction | If component thresholds are tuned per profile in the Sensitivity tab, the composite shifts accordingly. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes divergence | | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | [`supabase.supavisor-pool-saturation`](/nerve-centre/kpi-cards/supabase/supavisor-pool-saturation) | A red pool reading should be visible as the dominant drag in the score breakdown. | If saturation is red but the score barely moved, the component thresholds have been relaxed in Sensitivity. | | [`supabase.database-disk-usage`](/nerve-centre/kpi-cards/supabase/database-disk-usage) | Disk above 90% should drop the score even with everything else green. | A green score with high disk means the disk threshold was raised; revisit it before the project hits read-only mode. | ## Known limitations / FAQs **The score is 64 but every individual chart looks fine to me. What gives?** At least one component is in its red band; the composite cannot read low without one. Open the component breakdown or the sibling cards and look for the metric whose own gauge is amber or red. The most common culprits are pool saturation during a burst and disk usage creeping toward the tier cap, both of which are easy to overlook on a busy dashboard. **Why not just average the components? A weighted-worst approach feels harsh.** Because a flat average lets four healthy signals mask one failing one. A project that is silently losing connections or about to hit read-only disk would average out to a comfortable 80 and nobody would investigate. The worst-of bias guarantees that a real problem always surfaces as a low score, which is the entire point of a single executive number. **Does Supabase publish its own health score I can compare against?** No. Supabase exposes the raw component metrics in Studio Reports and via Postgres system views, but there is no native composite. This card is a Vortex IQ roll-up, so the right way to reconcile it is component by component against native tooling, not against a single Supabase figure. **My project has no read replicas. Does that hurt the score?** No. When the project has no replicas, the replication-lag component is omitted from the blend rather than scored as zero. You are not penalised for not buying a paid feature you do not need. The component reappears automatically if you later add a replica. **How quickly does the score recover after I fix the underlying problem?** Usually within one to two refresh cycles. Each component has its own window, so a saturation event that clears instantly may still show for a single cycle while the rolling reading catches up. The `RT/7D` trend line is the better recovery indicator than the live value alone. **Can I change what counts as "healthy" for my workload?** Yes. Every component threshold is configurable per profile in the Sensitivity tab. An analytics-heavy project that legitimately runs hotter on disk or latency can relax those bands so the composite reflects its real baseline rather than the generic OLTP default. Tune deliberately, though: relaxing a threshold to silence a red is how a real problem gets hidden. **Should I alert on the score itself or on the components?** Alert on both, for different audiences. The score below 70 is the right page for an on-call platform lead who needs a single "something is wrong" signal. The component alerts (pool, disk, error rate) are the right pages for the engineer who needs to act, because they name the problem directly. The score is the executive lens; the components are the operational lens. *** ### Tracked live in Vortex IQ Nerve Centre *Supabase Health Score* is one of hundreds of KPI pulses Vortex IQ tracks across Supabase 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.