What an incident shows
- The blocker: how long its transaction was open, how long it sat idle inside, and its application name.
- The waiters: how many waited at once, and for how long behind the blocker.
- Deadlocks: the count, and the detail where dbtempo can read it. On MySQL and MariaDB that is the latest InnoDB deadlock report. On PostgreSQL it comes from the server log, through an agent on the database server.
- Connections near the usable limit, a server that refused a connection, and pools you declared that do not fit.
What it can and cannot see
- Short waits can be missed, and data can lag.
- Each incident says what was and was not recorded.
- An empty list says no incidents were seen only when recording covered the window.
Engines
Recording works on PostgreSQL, MySQL 5.6 and later, and MariaDB 10.6 and later. It is off by default and is turned on per database, and it needs a plan with connected collection, which Pricing lists.
What it does not do
- It does not stop a session. Advice to cancel or end a blocker is text you run yourself.
- It does not name a root cause. It says what was waiting, on what, and for how long.
- It does not open a pull request for an incident on its own.
Alerts
dbtempo can alert you on an incident, to the bell, email and Slack, as you choose per project.
Start
Sign up, connect a database, then turn on Record lock waits and Record long transactions in its dialog. The docs below list the permissions and exactly what is stored.