Platform

System

Saturation

CPU load

no data

Memory

no data

Disk

no data

Redis

no data

Memory · 24h

Not enough history yet

Disk · 24h

Not enough history yet

API request latency · 24h

p50 —p95 —p99 —req/s —errors —
Not enough history yet

Queue depth

No queue data yet

PostgreSQL

Connections
no data
Cache hit
no data
Database size
no data
Commits/s
no data
Rollbacks/s
no data
Outbox unpublished
no data

Slowest statements — database time

Time spent inside PostgreSQL. This is not request latency — it cannot see authorization, tenant scoping or serialization. Statements run by other database roles are not visible here.

No statement statistics available

Capacity

How much does this box hold?

The rate limiter binds before the hardware does

Measured 30 Aug 2026: throttling starts at 8 concurrent callers, while memory sat at 25%, database connections at 5 of 100, and CPU never became the limit. The configured ceiling is 20/s · 100/10s · 500/60s — a sustained ~8.3 requests per second.

That bucket is shared across every caller, not per client, so it is a platform-wide ceiling and one busy client can throttle everyone else. A bigger box would not move it by a single request.

What breaks first

  1. 1The rate limiter, at ~8.3 req/sConfigured, shared, and reached long before any resource. Fixing it is a config change, not a purchase.
  2. 2The per-tenant audit-chain lock, at ~150 req/s of writesMeasured separately on the money path. It is per tenant, and a school chain is one tenant — vertical scaling does not move a lock.
  3. 3CPU — 2 cores shared by six SSR servers, Postgres and a workerNot yet observed under real load. It is the first HARDWARE limit expected, ahead of memory.
  4. 4Memory, lastNot the near-term constraint.

Where the memory goes

The six Next.js apps consume 991 MB of 1380 MB of container memory — 72% — while the API, worker, Postgres and Redis together use 389 MB.

It is a fixed tax paid before any user arrives and it does not grow with tenants. So the first upgrade buys headroom for traffic, not for schools — and the cheapest capacity win is not a bigger tier at all.

Measured 30 Aug 2026 · docker stats

Box tiers

TiervCPURAMDiskLeft after portalsBasis
KVM 114 GB50 GB~1.7 GBprojected· 1 vCPU is the risk, not RAM
KVM 2current28 GB100 GB~5.7 GBmeasured 30 Aug 2026· current — confirmed from the Hostinger API
KVM 4416 GB200 GB~13.7 GBprojected· first tier with real SSR headroom
KVM 8832 GB400 GB~29.7 GBprojected· far beyond anything measured

⚠️ Only the KVM 2 row is measured. Every other row is arithmetic from published specs and has never been run — treat it as a starting point for a test, not as a result.

Growth to exhaustion

Disk
no data

Sawtooths weekly: Docker build cache accumulates ~12 GB per deploy and a Sunday cron reclaims it. Judge it on the peak, never on a spot reading.

Database
no data

2 tenants and 48 students. Far too small to extrapolate a per-student cost from — that needs a seeded load test, not arithmetic.

Connections
no data

Never approached under load. Not a constraint at this scale.