Skip to main content

Usage Metrics


Usage information does not currently display for High Availability (HA) deployments.

Usage metrics were originally introduced in release 3.61.0 but were revised in release 3.66.0. This topic covers the current implementation.

After logging in, Nexus Repository administrators are able to view usage statistics for a Sonatype Nexus Repository instance on their home screens.

Depending on whether you are using Sonatype Nexus Repository Pro or OSS, you will see the following information about this instance's usage:


Shown for OSS/Pro

What it Means

Total components

OSS & Pro

Total number of components in this Sonatype Nexus Repository instance across all repository formats.

Calculated by counting each individual component record in the database (i.e., ${format}_component table).

Docker components are aligned with Docker manifest tags. Layers are treated as assets and not considered in the component count.

Unique logins

OSS only

Unique successful logins to this Sonatype Nexus Repository instance in the last 30 days.

Calculated by identifying a userID and realm combination as an individual identifier.

Only considers requests to the /repository/* urls.

Peak requests per minute

OSS & Pro

Maximum number of requests per minute to repository endpoints for all repositories in this Sonatype Nexus Repository instance over the past 24 hours.

Only considers requests to the /repository/* urls.

Peak requests per day

OSS & Pro

Maximum number of requests per day to repository endpoints for all repositories in this Sonatype Nexus Repository instance over the past 30 days.

Only considers requests to the /repository/* urls.


Usage metrics data updates hourly at the top of the hour. Newly generated requests, users, or components will not be accounted for in real-time.

Usage Threshold Tracking for Embedded Databases

Deployments using an embedded database will also see usage threshold trackers under the provided metrics.

This tracker will alert you when your usage begins to approach a point at which your scale is exceeding recommendations for using an embedded database. This includes the following:

  • 20,000 requests per day

  • 100,000 components

Usage metrics dashboard in Nexus Repository

While embedded databases are appropriate for disposable edge caches, test deployments, and low-concurrency team usage, an external PostgreSQL is recommended for more demanding use. This is particularly true for higher-concurrency use or in any situation where Nexus Repository is the system of record for the components that it stores.

Embedded databases require the system to enter read-only mode to get a consistent backup. Because of this, many deployments are not properly backed up, leading to extremely long recovery times in the case of an outage that requires restoring data.

Concurrent loads can lead to data integrity problems in OrientDB, which can make some or all components unavailable to users.

Pro customers on a PostgreSQL database will not see a threshold tracker. This is because you are already using a deployment model appropriate for your scale.


What to do When Usage Exceeds Recommendations for Your Deployment

When your Sonatype Nexus Repository usage approaches recommended levels for your deployment, you should begin planning a migration to an architecture that is more appropriate for your needs. If your usage is exceeding recommended levels, you should migrate to a new deployment model as soon as possible.

To help you determine a deployment model that is appropriate for your needs, we’ve created a series of reference architectures for Nexus Repository. Each architecture provides system requirements and deployment strategies to handle specific ranges of anticipated total load. We also provide sizing instructions so that you can appropriately evaluate your total projected load.

Implementing an appropriate deployment model may require upgrading to Sonatype Nexus Repository Pro, migrating to a PostgreSQL database, and exploring options such as high availability, resiliency, and content replication.