{% block page_subtitle %}Poll-based · summary every 2 min · snapshots every 15 min{% endblock %}
{% for r in ['1h', '6h', '24h', '7d', '30d'] %}
{% endfor %}
live
{% block content %}{% endblock %}
P50Median speed — half of all requests were faster than this
P9595% of requests were faster — 1 in 20 users waited this long
P99Worst-case speed — only 1 in 100 requests was this slow
DB %Share of response time spent waiting for the database
N+1A query that fires once per row instead of once in total
Performance Terms — Plain English
Every metric this dashboard shows, explained without jargon
Latency & Response Time
P50 — Median
Half of all requests finished faster than this number. Think of it as the "normal" speed that most users experience day-to-day.
P95 — 95th Percentile
95% of requests were faster than this. The remaining 5% — roughly 1 in 20 users — waited this long or longer. Good for catching hidden slowdowns.
P99 — 99th Percentile
99% of requests were faster than this. Only 1 in 100 users hits this delay. It represents your worst-case experience and is the first signal of serious performance issues.
Avg Response Time
The simple average of all request durations. Useful as a quick headline, but a single slow request can pull the average up — always check percentiles too.
SLA 300ms
Service Level Agreement threshold. Requests taking longer than 300ms are considered "too slow" by this dashboard's standard. The dashed line on latency charts marks this boundary.
Response Time (ms)
Total time from when the server received the request to when it finished sending the reply, measured in milliseconds. 1,000 ms = 1 second.
Database
Avg DB Queries / Request
On average, how many database lookups each API request triggers. Under 6 is healthy. 6–10 is a warning sign. Over 10 usually means an N+1 problem is present.
N+1 Problem
A common coding mistake: the app fetches a list (1 query), then runs a separate query for every item in that list. Fetching 50 users triggers 51 queries instead of 1. It gets drastically worse as data grows.
DB Time %
What percentage of the total response time was spent waiting for the database. 30% is normal. Over 50% means the database has become the main bottleneck slowing responses down.
DB Bottleneck (red rows)
An endpoint where DB Time % exceeds 50% — the database is now the biggest drag on performance. Fixing the queries (or adding caching) here will have the biggest impact on speed.
Max DB Queries
The highest number of database queries seen on a single request to this endpoint. A very high max alongside a normal average often reveals a specific edge-case triggering an N+1 loop.
Slow Requests (≥ 500ms)
Individual requests that took 500ms or longer. Listed with their DB query count and DB time so you can see whether the database or something else caused the slowdown.
Errors & Traffic
Error Rate
The percentage of all requests that returned an error (HTTP status 400 or above). Under 2% is healthy. Above 5% signals something is actively broken and needs attention.
4xx Errors
Client-side errors — the request itself was invalid. Examples: 404 Not Found, 401 Unauthorized, 403 Forbidden. Usually caused by bad input, expired tokens, or missing resources.
5xx Errors
Server-side errors — the server crashed or failed while handling the request. Examples: 500 Internal Server Error, 503 Service Unavailable. These always require investigation.
Concurrent Requests
How many HTTP requests the server is processing at exactly the same moment. A sudden spike means many users hit the server simultaneously, which can slow everyone down.
Peak Concurrency
The highest number of simultaneous requests seen in the selected time window. The server is under most strain at this moment.
~10% Sampled
To save storage, only 1 in 10 requests is stored in the summary table. The "Total Requests" KPI reflects this sampled count. All other tables record every request individually.
WebSocket
WebSocket
A persistent two-way connection between the browser and server — unlike normal HTTP requests which open and close instantly. Used for real-time features like chat, notifications, and live updates.
Connect / Disconnect
Connect = a user's browser opened a WebSocket. Disconnect = the connection closed (user left, network dropped, or the server closed it). Active connections = connects minus disconnects.
Inbound Messages
Messages sent from the browser to the server (e.g. "user is typing", "send this chat message"). Counted per Consumer handler.
Outbound Messages
Messages pushed from the server to the browser (e.g. "new notification", "another user replied"). High outbound vs inbound means the server is broadcasting a lot.
Processing Time (ms)
How long the server spent handling one WebSocket message before returning. High processing times here can make real-time features feel laggy.
Consumer
The Django Channels class that handles a group of WebSocket connections (e.g. ChatConsumer, NotificationConsumer). Each consumer type appears as its own row in the breakdown table.
Server Resources
CPU %
How hard the server's processor is working, as a percentage of total capacity. Under 60% is healthy. 60–80% is a warning. Above 80% the server is struggling and requests will slow down.
RAM %
How much of the server's memory is in use. Above 85% can cause the OS to start swapping to disk, which dramatically slows everything down.
File Descriptors
An OS-level counter for every open file, socket, and network connection. Each connected user typically takes one. A very high count can mean connections are not being closed properly (a connection leak).
CPU Heatmap
A 7-day × 24-hour grid showing average CPU usage by day of week and hour of day. Red cells = peak load periods. Useful for scheduling maintenance or identifying predictable traffic spikes.
Celery Queued Tasks
Background jobs waiting in the queue that no worker has picked up yet. A growing queue means your workers can't keep up with incoming work — you may need more worker processes.
Celery Active / Reserved
Active = tasks running right now. Reserved = tasks a worker has claimed but not started yet. Both are normal. Only "Queued" growing continuously is a problem.
Scale Decision Panel
Healthy ●
All metrics are within normal ranges. No action needed.
Monitor ●
Metrics are elevated but not critical yet. Watch the trend — if it keeps climbing, take action before it becomes an outage.
Scale Now ●
API or server metrics are at dangerous levels. Add more server capacity, increase worker count, or enable autoscaling immediately.
Optimize Queries ●
Database metrics are critical. The DB is the main bottleneck. Fix N+1 queries, add database indexes, or introduce caching to reduce query count.
Redis Blocked Clients
Redis connections waiting on a blocking command (like waiting for a new task in a queue). A small number is normal for Channels/Celery. A large sustained count signals backpressure — jobs are piling up faster than they're consumed.
PG Connection Pressure
Active DB connections ÷ (active + idle) × 100. Near 100% means almost all connections are in use at once — if it stays this high, new requests may be queued waiting for a free DB connection.
Export performance report
Pick a range and report, preview it, then download as PDF or email it.
Date range
{% for r in ['1h', '6h', '24h', '7d', '30d', 'all'] %}
{% endfor %}