What an incident is
An incident is a stretch of time when statements on one database were seen waiting on a lock another session held, grouped into one record.
Example: an api transaction holds a row lock for 40 seconds while six UPDATE statements queue behind it. dbtempo shows one incident, names the application that held the lock and how long it sat idle, and lists the six waiters.
Open the Incidents view
- Open the project's Activity tab. Choose Incidents. The list runs up to 14 days back. The project Overview also shows a Needs attention row and a 24 hour lane.
- Open an incident. The sheet starts with: Started, Blocker open, Waiters (peak), and Behind the blocker.
What the sheet shows
| Section | What it answers |
|---|---|
| Who was involved | The blocker, with how long it was open, when dbtempo has a transaction record for it. |
| What happened, in order | A timeline, and it says when it is cut short. |
| What was collected | For each source, its state and how much of the incident it covered. |
| Deadlocks | The deadlock count, and the detail where dbtempo can read it. |
| Advice | Text you can run yourself. dbtempo never runs it. |
| Nearby, not linked | Waits and transactions that overlapped in time but have no link to the incident. They do not change its level or counts. |
Medium and High
An incident is Medium and becomes High when waits are long, many statements are blocked, or connections are nearly exhausted. The level is an ordering, not a verdict.
Read the coverage before you trust a gap
Each source says what it recorded, for example "Lock waits: recorded the whole time." or "recorded for 4 min of the incident." An empty list says no incidents were seen only when the whole window was recorded. Otherwise it says how much was.
MariaDB shows no holder for a metadata-lock wait, and cannot see advisory locks (GET_LOCK). MySQL and MariaDB keep no server-log events.
Choose where alerts go
In Settings, Notifications, the toggle A lock or open-transaction incident is on by default. It needs Record lock waits.
- The bell always gets the alert. Email is on by default. Slack once connected.
- Alerts are rate-limited per database, and you can route or mute them per project.
- Alerts are not instant, so an alert can trail the start of an incident.
dbtempo applies nothing for an incident
Stopping a session (pg_terminate_backend on PostgreSQL, KILL on MySQL and MariaDB) appears as text under "Advice: if you need to stop the blocker (advice only)". You decide, and you run it. Code findings linked to an incident are suggestions and never open a pull request on their own.
Next
Find what is blocking a query in PostgreSQL shows the same facts from the database's own views.