This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
## Problem
The "Healthy / Unhealthy" badge on the Observability overview was
alarming — showing **UNHEALTHY** even when every bar in the chart looked
fine. Two root causes:
1. **The threshold is aggressive.** Any period where the aggregate error
rate is ≥ 1% flips the badge to "Unhealthy", even if that 1% came from a
short burst that is visually indistinguishable in the chart.
2. **Period-wide aggregation hides spikes.** The badge status is
computed over the entire selected time window (e.g. 24 h). A 5-minute
spike at 20% errors diluted across 24 h of mostly-clean traffic can push
the aggregate just over 1%, triggering "Unhealthy" while all chart bars
look green.
The badge wording ("Unhealthy") also implies a current service problem,
whereas the underlying metric is a historical aggregate — making it easy
to misread.
## Change
Remove the badge entirely. The per-row error/warning rate indicator
(e.g. `● 1.34% errors`) already surfaces the key signal without the
alarming label, and the bar chart lets users see the actual shape of
traffic over time.
## On spike visibility in charts
The charts already use **COUNT per time bucket** (not averages), so
individual bars faithfully represent event volume. The bucket
granularity does compress spikes for longer windows (hourly buckets for
1–3 day views, daily for 7-day), but that's a separate concern from the
badge. If we want to surface burst detection in the future, a better
approach would be per-bucket threshold highlighting rather than a single
period-wide badge.
https://claude.ai/code/session_01E1ejWyuR9BV4qcTyiGGVVY
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Removed the service health status indicator from the Service Health
Table.
* **New Features**
* Replaced per-row bar charts with a line chart showing error/warning
rates alongside OK series.
* Added a centered "No data" placeholder when chart data is empty and
preserved click interactions on chart points.
* Y-axis values now display as percentages.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Problem
On self-hosted Supabase instances where the `pg_stat_statements`
extension is not installed, the Observability Overview page
automatically queries the extension on every page load. This produces
"relation pg_stat_statements does not exist" errors in Postgres logs for
all projects without the extension. Additionally, if a user navigated to
the Query Performance page, they received a generic error with no
actionable guidance. A secondary issue allowed malformed sort URL params
(e.g. `?sort=created_at:asc&order=asc`) to be interpolated directly into
SQL ORDER BY clauses.
## Fix
- Wrapped the `useSlowQueriesCount` SQL in a `CASE WHEN EXISTS (SELECT 1
FROM pg_extension WHERE extname = 'pg_stat_statements')` guard. The
query now returns 0 silently instead of erroring when the extension is
absent.
- Added a `VALID_SORT_COLUMNS` whitelist in
`generateQueryPerformanceSql`. Invalid column names from URL params are
rejected and the query falls back to the preset default ORDER BY.
- When the Query Performance page fails because `pg_stat_statements`
does not exist, a `warning` admonition now appears with "Enable it in
Database -> Extensions" guidance instead of a generic destructive error.
The Sentry capture is skipped for this expected configuration state.
- Extracted `buildSlowQueriesCountSql` as a testable function and added
unit tests for both fixes.
## How to test
**Extension not installed (self-hosted):**
1. Run a self-hosted Supabase instance without the `pg_stat_statements`
extension enabled.
2. Navigate to the Observability Overview page.
3. Check Postgres logs -- no "relation pg_stat_statements does not
exist" errors should appear.
4. Navigate to the Query Performance page.
5. Expected: a yellow warning admonition appears saying the extension is
not enabled, with a link to Database -> Extensions. No red error.
**Extension installed (normal flow):**
1. With `pg_stat_statements` installed, navigate to Observability
Overview.
2. Expected: slow queries count loads as normal.
3. Navigate to Query Performance -- data loads as normal.
**Invalid sort URL param:**
1. Navigate to
`/project/<ref>/observability/query-performance?sort=created_at:asc&order=asc`.
2. Expected: the page loads and falls back to the default sort order
(total time descending). No SQL error in logs.
**Unit tests:**
```
node apps/studio/node_modules/vitest/dist/cli.js run --no-coverage \
apps/studio/components/interfaces/Observability/useSlowQueriesCount.test.ts \
apps/studio/components/interfaces/QueryPerformance/useQueryPerformanceQuery.test.ts
```
All 28 tests should pass.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
The `homeNew` PostHog experiment has concluded. This PR graduates it by
making the new homepage (`ProjectHome`, formerly `HomeV2`) the permanent
default for all users, and removes all dead code from the old
experiment.
## Changes
- Remove `homeNew` PostHog feature flag checks and `home_new` experiment
exposure tracking from 3 files
- Rename `HomeNew/` → `ProjectHome/` directory and `HomeV2` →
`ProjectHome` export
- Delete old `Home/Home.tsx` component (shared components like
`ProjectList/` are kept — still used by org pages)
- Delete `pages/project/[ref]/building.tsx` and add a server-side
redirect from `/project/:ref/building` → `/project/:ref` to prevent 404s
during rollout (old cached JS bundles may still route to `/building`)
- Simplify `ContentWrapper` building-state logic in `ProjectLayout` —
always redirect building projects to home, always suppress building
interstitial on home page
- Always route to `/project/{ref}` after project creation (remove
`/building` path)
- Update all Observability imports from `HomeNew` → `ProjectHome`
## Self-hosted behavior change
Self-hosted Studio previously showed the old `Home` component (client
libraries + example projects) since PostHog flags don't load. This PR
changes self-hosted to show `ProjectHome` (TopSection with service
status + instance diagram, advisor, custom reports). All sections query
backend APIs that exist on self-hosted. E2E tests pass against the
self-hosted build.
## Testing
- [x] `pnpm turbo run build --filter=studio` passes
- [x] No remaining references to `homeNew`, `home_new`, or `HomeNew` in
codebase
- [x] No broken imports to deleted files
- [x] Self-hosted E2E tests pass (145 passed, 1 flaky, 4 skipped)
- [x] `/building` redirect added to both platform and self-hosted config
blocks
**Quick test:**
1. Navigate to any project homepage — should render the ProjectHome
component
2. Create a new project — should redirect to `/project/{ref}` (not
`/building`)
3. Visit a project in `COMING_UP` state on a non-home route — should
redirect to home
4. Visit `/project/{ref}/building` directly — should 302 redirect to
`/project/{ref}`
## Linear
- fixes GROWTH-671
### Changes
- Replace plan-based checks (`LOG_RETENTION`, `availableIn`) with
`useCheckEntitlements('log.retention_days')` in the chart interval
dropdown
- `ChartIntervalDropdown` now calls the entitlements hook internally
instead of receiving plan props
- Remove `LOG_RETENTION` constant and `availableIn` from
`CHART_INTERVALS`
- Update consumer components (`ProjectUsage`, `ProjectUsageSection`,
`ObservabilityOverview`) to remove plan prop passing
### Testing
- Head to `/project/_/observability` with a Free plan org.
- Click on the time selector "Last 7 days" is disabled, default is "Last
60 minutes", tooltip shows retention limit and upgrade link
<img width="827" height="151" alt="image"
src="https://github.com/user-attachments/assets/20988398-8f0a-46b6-be3d-af4e9d530f81"
/>
- With a Pro Org and above the "Last 7 days" option should be enabled
## Context
Follow up from https://github.com/supabase/supabase/pull/43329, but
mutually exclusive
Just cleaning up feature flags that have been toggled on for all users
and unchanged for the past 2 months
- edgefunctionreport
- storagereport
- realtimeReport
- postgrestreport
- authreportv2
- newEdgeFunctionOverviewCharts
- apiReportCountries (Already not used)
- SentryLogDrain
- reportGranularityV2
- storageAnalyticsVector
- ShowIndexAdvisorOnTableEditor
- adds disk IO
- removes error rate (its in the first row in the second section anyway)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added Disk IO metric card to monitor disk input/output performance in
real-time.
* **Changes**
* Removed Error Rate metric from database infrastructure monitoring
dashboard.
* Renamed "Disk" metric to "Disk Usage" for improved clarity.
* Enhanced disk metrics with refined measurements and calculations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Observability Dashboard: unified overview for service health and
database infrastructure with interactive charts and metric cards (CPU,
memory, disk I/O, connections, error rate, slow queries).
* Service Health Monitoring: per-service health cards and a
multi-service table with error/warning counts and drill-down links to
reports/logs.
* Interval Selector: new chart-interval dropdown with plan-aware
retention messaging.
* Menu & Reports: updated Observability menu with Overview entry and
Custom Reports management.
* **Documentation**
* Added a footer link to troubleshooting guides.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Safer error rendering across analytics and reporting with a fallback
"Unknown error".
* **Tests**
* Added unit tests covering timeseries sorting and timestamp validation.
* **Refactor**
* Standardized timeseries hook and all callers to accept a single
options object and improved nullish handling.
* **New Features**
* Exposed timeseries utilities and explicit options/result types;
exported chart data type.
* **Chores**
* Relaxed index signatures to allow dynamic metric keys.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- refactors new charts in homepage to use stable analytics endpoints
- changes are behind newHomepageUsageV2 flag
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Centralized per-service health metrics hook with per-service data,
loading/error states and refresh.
* **Improvements**
* Time-series normalization into fixed buckets aligned to an end time.
* Updated UI: success-rate formatting, per-service loading/error
surfaced, refreshed click/refresh behavior; removed delta display.
* **Removals**
* Legacy project-metrics query and mapping utilities removed.
* **Tests**
* Extensive unit tests added for date ranges, bucket normalization, and
health metric calculations; some obsolete tests removed.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Ivan Vasilov