Smart monitoring: how PWR detects PostgreSQL incidents before your users do
6 min read
How PWR watches your database continuously, tells a simple passing spike apart from a real incident, and automatically alerts your team by email before your users even complain.
Monitoring that never stops
Most monitoring tools only show a database's state when someone is looking at the screen. PWR works differently: a check happens automatically every minute, for each of your connected databases, whether or not your team has a dashboard open at that moment.
In practice, this means a slowdown that starts on a Sunday evening or during a night on-call shift is caught exactly the same way as an incident happening in broad daylight in front of a screen — nobody needs to be looking at PWR for the monitoring to work.
Not confusing a passing spike with a real problem
A database constantly experiences small variations in activity: a spike lasting a few seconds, a query that's occasionally slower, a user running a heavy job just once. Reacting instantly to every one of these variations would create more noise than signal, and would end up wearing out a team flooded with false alerts.
PWR therefore watches the database's behavior over time before drawing a conclusion: it tracks how long in a row the situation stays degraded, how long it stays in a warning zone, and how long it stays healthy. An incident is only recognized as such once the degradation is confirmed over several consecutive minutes, never based on a single isolated reading.
React fast to a problem, confirm a return to normal cautiously
PWR deliberately applies two different speeds depending on which way the situation is moving. To flag a problem, a few minutes of confirmed degradation are enough: it's better to warn your team a little early than to let an incident settle in without a reaction. To announce a return to normal, on the other hand, PWR waits for a noticeably longer period of stability before confirming it.
This asymmetry is not accidental: it avoids two opposite pitfalls. On one side, it prevents reassuring a team too early with an "everything's fine" message while an incident is still stabilizing and could flare up again. On the other, it guarantees that a real problem is never ignored for long, since it is flagged as soon as it is confirmed, without needless waiting.
A targeted email alert, not a flood of notifications
As soon as a state change is confirmed, two things happen. First, the event is recorded in your database's history: date, severity, context — this trace stays available even if no email is ultimately sent, to keep a complete record of what happened. Then, a notification is emailed to every member of your workspace, so the whole team is informed at the same time, without depending on a single person being logged in at the right moment.
To prevent an unstable database oscillating between two states from flooding your inbox with dozens of messages in a few minutes, PWR enforces a short minimum delay between two alerts sent for the same database: the full history is always tracked, but email sending is smoothed out to stay manageable on a daily basis.
When the situation becomes durably stable again, a second email explicitly confirms the return to normal and states the total duration of the incident — your team thus knows not only that a problem occurred, but also precisely how long it lasted and when it was resolved.
What this concretely changes for your team
An isolated spike lasting a few seconds will never trigger an email: it doesn't have time to be confirmed over the duration PWR requires. A real incident that settles in, on the other hand, is flagged in just a few minutes, well before it has time to worsen or your users start complaining.
The intended result is simple: your team receives a reliable alert, at the right time, without unnecessary noise — and a clear confirmation once the incident is actually over.