If you have performance monitoring enabled and your application queries a database, you can see how your queries are performing in Sentry.
Sentry's query monitoring helps you investigate the performance of your queries and get more information to improve them.
Starting with the Queries page, you get a high-level overview of how your queries are doing. From there, you can drill into a specific query's Query Summary page and then investigate sample events from the Sample List to better understand the context of its performance in a specific endpoint.
The gif below demonstrates how to use performance monitoring for queries.
The queries widget and pages are only available for backend projects with performance monitoring enabled.
Query monitoring works best with up-to-date SDK versions. The following minimum versions are recommended:
- Python SDK v1.29.2
- Laravel SDK v3.8.0
- Cocoa SDK v8.11.0
- Java SDK v6.29.0
- Ruby SDK v5.11.0
- .NET SDK v3.39.0
- Symfony SDK v4.11.0
- Android SDK v6.30.0
Sentry tries to extract metrics for all SQL-like dialects. NoSQL databases like MongoDB, graph databases like Neo4j, and other non-SQL database systems are not currently eligible for this feature.
If you are using
- The span
opfield is set to an eligible value.
- The span's description contains the full, parameterized SQL query (e.g.
"SELECT * FROM users WHERE id = ?"). Supported placeholder values are
db.systemspan data value is set to the correct identifier (e.g.,
The Queries page gives you a quick overview of your application's query performance for the selected
Open the Queries page by clicking "Queries" in the sidebar, under "Performance". Alternatively, the Performance page also surfaces the highest impact queries in the "Most Time-Consuming Queries" widget. From there, you can click "View All" to open the Queries page.
At the top of the page, summary graphs for queries per minute (throughput) and average duration provide high-level insight into your database performance. If you see an anomaly or want to investigate a time range further, you can click and drag to select a range directly in a graph to filter data for that time range.
The query description table below shows a list of queries, along with their volume (queries per min), average duration, and the total time your app spent running that query (time spent). The query descriptions are parametrized, so your queries may look slightly different.
By default, this table is sorted by most time spent. This means that queries at the top are usually really slow, very frequent, or both. You can change this to sort by queries per minute to see the most frequently run queries, or by average duration to see the slowest queries.
You can also use the dropdowns above to filter the table for specific SQL commands (such as
UPDATE) and tables queried.
To view more details, click on a query from the table to open its Query Summary page.
The gif below provides a detailed walkthrough of the Queries page.
In some cases, Sentry processes queries and simplifies them to improve readability. For example:
- Table names are removed from column selections if possible (e.g.,
SELECT "users"."name", "users"."id", "users.age" FROM usersbecomes
SELECT name, id, age FROM users)
- Long lists of
SELECTarguments are collapsed (e.g.,
SELECT id, name, age, city, country, phone FROM usersbecomes
SELECT .. FROM users)
- Long lists of
VALUESarguments are collapsed (e.g.,
INSERT INTO users (id, email, name, age) VALUES (%s %s %s %s)becomes
INSERT INTO users (..) VALUES (%s))
CASE / WHENstatements are collapsed
You can see the full query by hovering on a truncated description, or clicking it to see its Query Summary page.
To open a query's Query Summary page, click on the query from either the table in the "Most Time-Consuming Queries" widget on the Performance page or the table in the Queries page.
At the top of the page, queries per minute, average duration, and time spent are shown for the selected time range. The full query is shown below these metrics, followed by graphs for queries per minute and average duration.
At the bottom, you can find a list of endpoints the query is found in, sorted by the most time your application spent in that span.
If you want to investigate a specific endpoint, click on it to open a sidebar showing some sample events.
The gif below provides a detailed walkthrough of the Query Summary page.
Click on an endpoint to open its samples list. This side panel shows summary metrics (QPM and average duration) for the query in the specific endpoint.
The table shows a sample list of events, their span duration, and the difference in duration compared to average. This table is sorted by longest span duration.
Sentry automatically finds a variety of samples to help you investigate performance problems. The chosen events will cover the entire selected time range, as well as a range of durations (both faster than, slower than, and near the average duration). You can get a sense of the performance characteristics by comparing different sample events.
These same events are also represented as triangles shown in the average duration graph above.
You can generate a new list of random sample events by clicking the "Try Different Samples" button at the bottom.
From the sample list, you can drill down to specific good, average, or bad examples of a given query within a given endpoint. Click on an event ID to drill into the query's span details within the span waterfall of the Event Details page.
The gif below explains how to navigate the sample list.
By default, queries are sorted by time spent, which serves as a proxy for the relative impact of a given query.
Every database query takes some time to execute. When an application sends a query, it waits for the database to receive the query, parse it, execute it, and return the result. In Sentry, the total time taken from sending the query to receiving the full result is called the query's duration. The query's time spent is the sum of all its durations in a given time period.
For example, an application might send a query like
SELECT * FROM users LIMIT 10 every time a user calls the
/users endpoint. The query might take anywhere from 100ms to 200ms to run, and the endpoint is called anywhere from 10 times a minute to 100 times in a minute depending on the time of day. The query's time spent is the sum of all of its durations that occurred in a given time period. Put another way, the time spent is the product of the average duration and queries per minute. In a high-throughput application, a query's time spent might be measured in weeks or months.
Time spent is a useful way to measure a query's relative impact, compared to other queries in an application. For example, if one query's time spent is 7 days, and another is just 2 hours, the query with more time spent is probably more impactful to fix. Even a small improvement in duration would result in a meaningful overall improvement. Time spent can also be a strong signal that something is wrong. Queries that suddenly start taking up more time are often signal a problem.