Slowdowns, errors, locks, saturation: what you notice, what Wakoo finds, the fix, and how Wakoo checks it held. Examples, values illustrative.
First instance freeRead-only
First real peak, and the app answers FATAL: too many connections.
Wakoo finds
60 serverless instances × a pool of 10 = 600 connections, above the limit of 500.
FixA transaction pooler in front, pools capped at 2.
Active connections against the limit, at the next peak.
The CPU climbs, and yet every query looks fast.
Wakoo finds
One 0.4 ms query runs 38,000 times a minute: an N+1 from the ORM.
FixEager-load the relation: one query instead of thousands.
Calls per minute for that query shape.
Nobody shipped anything, and a report now takes 11 s instead of 0.3 s.
Wakoo finds
After ANALYZE, the planner expects 40 rows instead of 2.3 M and picks a nested loop.
FixExtended statistics on (status, account_id). No write lock.
Plan shape and p95 of that query.
Nothing changed, and yet it all slows down: scans on events get longer every month.
Wakoo finds
61% dead rows; autovacuum hasn't finished on events in 9 days.
FixTune autovacuum for that table. Reclaim space later if needed.
Dead-row ratio and scan time on events, each week.
One ALTER TABLE, and every request times out.
Wakoo finds
It waits behind a transaction idle for 47 min; every query queues behind it.
FixRetry with lock_timeout, and fix the worker that leaves transactions open.
No long idle transaction before the next migration.
Since Thursday, the orders list takes 4 s instead of 200 ms.
Wakoo finds
A new query sorts 1.2 M rows and writes 800 MB of temp files per run.
FixAn index matching the ORDER BY, built CONCURRENTLY.
Temp files and mean time of that query, before and after.
How the diagnosis works: see the product.
One Node.js script, run on your machine with a read-only role. It prints a report on your screen and sends nothing anywhere.
A person from the team emails you the script within 24 h.
First instance freeRead-only