> ## Documentation index > Fetch the complete documentation index at: https://upstash.com/docs/llms.txt > Search it with GET https://upstash.com/docs/search?q=. > Use these to discover all available pages before exploring further. # Insights > See how your Redis database is routed, how it performs, how close it is to its limits, and what its keyspace holds. The **Insights** tab on the database page of the [Upstash Console](https://console.upstash.com) shows what is going on inside your database. It has five views: Traffic, Performance, Limits, Lua and Keyspace. Insights is a [Prod Pack](/redis/overall/enterprise#prod-pack-features) feature, also included in Enterprise plans. Databases without Prod Pack see the tab with sample data, so you can explore it before you enable Prod Pack. Insights is not available for databases created through Fly.io, Heroku or DigitalOcean. Every view except Keyspace has a period picker in its top-right corner. You can look at the past hour, 3 hours, 12 hours, day, 3 days, week or month. ## Traffic ### Request routing Upstash serves requests from the region closest to the client. This section shows where each request entered and which region of your database answered it. Request routing in the Traffic view of the Insights tab - **Requests**: total requests in the period, how many were served in the region where they entered, how many were served in another region, and how many failed. - **Routes on the map**: each route from an entry region to the database region that served it. Dashed arrows are cross-region requests. - **All routes**: each route with its request count, share of requests, active and total connections, ingress and egress traffic, and errors. Cross-region requests are expected. Writes always go to the primary region, and reads go to the nearest replica. If many reads cross regions, adding a [read region](/redis/features/globaldatabase) close to those clients reduces their latency. ### Where clients connect from The IP ranges your requests came from, busiest first, with the cloud and region each range belongs to. Ranges are matched against the IP ranges that AWS, Google Cloud and Cloudflare publish. Serverless platforms show up as the cloud they run on, for example Vercel functions as AWS. The IP ranges clients connect from Client addresses are shortened to their /24 range, the first three parts of the IP, so individual addresses are not stored. ### Client types The SDKs, platforms and runtimes your clients use, from the telemetry headers that Upstash SDKs send. For TCP clients, the SDK is the library name they declare with `CLIENT SETINFO`. SDKs, platforms and runtimes of the clients ## Performance Charts of throughput, bandwidth, disk size and latency. Pick a replica in the top-left corner to see a single replica instead of all of them. The Simple service latency chart has its own picker for the p50, p90 and p99 percentiles. Throughput and bandwidth charts in the Performance view | Chart | What it shows | | --- | --- | | Throughput | Commands processed per second, including each command inside a pipeline or script. Console and non-billable commands are excluded. | | Bandwidth | Bytes transferred between clients and the database per second, in and out combined. | | Disk size | Size of the data persisted on disk on a single replica. This is stored bytes, not memory in use. | | Simple service latency | Time from reading a request to writing its response, for requests where every command is a single-key read or write. | | Read service latency | The same, for requests where every command is read-only. | | Write service latency | The same, for requests that include at least one write. | | Command execution latency | Time spent executing the command itself, without parsing, lock waits, disk loads and writing the response. | | Replication latency | Time a write waited for replication before its response was sent. | | Lock wait latency | Time a command waited for its key locks. Grows with contention on hot keys. | | Lua execution latency | Time spent executing `EVAL`, `EVALSHA` and `FCALL`, including the commands the script runs. | | Expired entries | Keys removed per minute because their TTL passed. | | Replication lag | Updates written on the primary that have not been sent yet to the replica in each region. | ## Limits How close the database is to the limits of its plan, and the requests a limit refused or delayed. Usage against plan limits and command rejections - **Storage**, **Connections** and **Peak commands / sec**: current usage against the limit of the plan. - **Command rejections**: requests refused or delayed because of a limit, such as oversize requests, oversize keys, throttled writes, requests that could not reach any replica, and authentication failures. Each row shows when the rejections happened, how many there were, and when the last one was. If you keep running into a limit, see [upgrading your database](/redis/howto/upgrade-database). ## Lua Script counters, Lua latency, and the scripts that run most often. Lua script counters, latency and the most executed scripts The **Scripts** table lists the ten most executed scripts of the day, with their executions, the commands they ran, failures, and their average and maximum duration and memory. It counts from the daily UTC reset, whatever period is selected. Failures include timeouts and memory limit hits. ## Keyspace An analysis of what your keys hold, made from an offline scan of the latest daily backup. It does not run any command on your database. Keyspace summary, key types and biggest keys - **Summary**: number of keys and elements, logical size, keys without a TTL, and keys that had already expired. - **Key types**: for each Redis data type, the number of keys, their total size, key size and element count percentiles, and the largest key. - **Biggest keys**: the ten largest keys, with their type, element count and remaining TTL. - **Expiration profile**: keys grouped by remaining TTL. The keyspace is analyzed after every daily backup, so [daily backups](/redis/features/backup) must be turned on. The analysis is not available for HIPAA-compliant databases.