UnifiedMetrics gives a Minecraft server Prometheus metrics and a Grafana dashboard in one plugin

One plugin, five server platforms, two metric backends

UnifiedMetrics is a fully-featured metrics collection plugin for Minecraft servers, licensed under GNU LGPLv3, and the platform compatibility list is the headline feature.

The supported servers are Spigot 1.8 and newer, which includes Spigot-based forks, Fabric 1.16 and newer, Minestom, Velocity and BungeeCord. The supported metric backends are Prometheus and InfluxDB.

The claimed benefit of that breadth is the same metrics and features on any supported platform. A server operator running a Spigot network and a Velocity proxy in the same week does not have to learn two plugins with two configuration formats and two metric names.

The other claims in the feature list are the usual ones for a metrics plugin, with one worth unpacking. The high performance metric collection claim is qualified as low to none performance impact on the server's performance, which for a Minecraft server is the point. The tick duration histogram in the collector table is the metric that tells you whether the server is keeping up with its tick budget, and a plugin that measures that must not itself be the reason the tick slips.

The README also links a live Grafana dashboard preview at unifiedmetrics-demo.cubxity.dev, and the dashboard is documented as included out of the box rather than as something you build.

The collectors, and which platforms they actually run on

The collector table is the most useful part of the README, because it tells you exactly what you get and where the gaps are.

| Collector | Description | Platform | Default | | ------------- | ----------------------------------------------- | ---------------- | ------- | | systemGc | Garbage collection duration and freed bytes | All | true | | systemMemory | Memory used, committed, max and init | All | true | | systemProcess | CPU load, seconds, and process start time | All | true | | systemThread | Current, daemon, started, and peak thread count | All | true | | events | Login, join, quit, chat, and ping event counter | All | true | | server | Plugins count and player counts | All | true | | tick | Tick duration histogram | Bukkit, Minestom | true | | world | World entities, players, and chunks count | Bukkit, Minestom | true |

Six collectors run everywhere. The two that do not are tick and world, both marked Bukkit and Minestom only, and the reason is structural rather than accidental. A tick duration histogram needs a server tick loop, which a proxy does not have, and world entity, player and chunk counts need a world, which a proxy also does not have.

So a Velocity or BungeeCord deployment gets the JVM level metrics, the event counters and the server counts, and no tick or world metrics. That is the honest shape of the platform claim, and knowing it saves you from writing a dashboard panel that will never populate.

Every collector is enabled by default, which is a reasonable default for a monitoring plugin that has no meaningful cost when nothing is watching, but it does mean the first thing you do after installing it is decide what you actually want.

Building it, and the one flag that trips people up

The build requirements are listed as JDK 8 or newer, with 16 or newer for Fabric and 17 or newer for Minestom, and Git described as optional.

You obtain the source and build it in two steps.

$ git clone https://github.com/Cubxity/UnifiedMetrics && cd UnifiedMetrics

$ ./gradlew assemble -x signArchives

The README calls out the flag explicitly: `-x signArchives` is required to skip signing, unless you have signing set up. Without it the build fails at the signing task for anyone who does not have the release keys, and the message is not always obvious about what it wants.

The assemble task builds all subprojects, and the output artifacts land in `subproject/build/libs`. To build just one, you prefix the subproject path.

$ ./gradlew :unifiedmetrics-platform-bukkit:assemble -x signArchives

The module layout explains the platform strategy. There is a core/ directory, a common/ directory, a drivers/ directory, an api/ directory, a platforms/ directory and an examples/ directory, with build.gradle.kts and settings.gradle.kts at the root. The platform-specific code lives under platforms/ while the metric definitions live in common or core, which is how the same collector name can be produced by a Spigot plugin, a Fabric mod, a Minestom plugin and a Velocity plugin.

The API for people writing their own collector

The API module is published separately to Maven Central under the group dev.cubxity.plugins with the artifact unifiedmetrics-api, and there is a Sonatype Nexus badge for development builds alongside the release badge.

The Gradle setup for a consumer plugin is short, and the repositories block includes mavenCentral plus the Sonatype snapshots repository, which the comment marks as only required for -SNAPSHOT versions.

repositories {
    mavenCentral()

    // Snapshots repository (only required for -SNAPSHOT versions)
    maven("https://s01.oss.sonatype.org/content/repositories/snapshots/")
}

The dependency is declared compileOnly, with the comment asking you to replace the version with the one you want.

dependencies {
    // Replace this with the desired version
    compileOnly("dev.cubxity.plugins", "unifiedmetrics-api", "0.3.6")
}

And usage is a single static accessor.

import dev.cubxity.plugins.metrics.api.UnifiedMetricsProvider

/* ... */

val api = UnifiedMetricsProvider.get()

The README's guidance on wiring it in is to add `:unifiedmetrics-api` as a compileOnly or provided dependency, and to prefer using the platform's service manager if possible. That last instruction is the important one for anyone extending the plugin: you are not supposed to instantiate a metrics provider yourself, you are supposed to let the platform inject it.

There is an examples/ directory with example plugins, and the repository root shows a single example project named collector-zombies, which is the smallest useful thing to read to see how a custom collector is written.

Release cadence, the dev branch and what the tags tell you

The release list is the thing to check before you deploy this on a server you care about.

The most recent listed release is v0.3.x-SNAPSHOT, labelled as the development build for 0.3.x, dated 2025-04-11. Before that come v0.3.8 from 2023-04-23 and v0.3.7 from 2022-09-25.

So the newest tagged release is 0.3.8 from April 2023, and the 0.3.x line has been carried as a development build since. The default branch is dev/0.3.x, which is a branch-per-minor-line arrangement rather than a single main branch.

The last push to the repository was on 2026-10-20, so the code is being worked on. The gap between that and the last tagged release is the thing to weigh: for a plugin running on a live Minecraft server, the version you can safely reference is 0.3.8, and anything newer is a development build.

The API example in the README uses version 0.3.6, which is older than the newest tag, so it too is a snapshot of the intended usage rather than the current release.

The repository also carries both COPYING and COPYING.LESSER at the root, matching the LGPLv3 claim, and the topics list covers both the plugin platforms and the monitoring stack: api, bukkit, folia, spigot, minestom-extension, velocity, prometheus, prometheus-exporter, influxdb, grafana, grafana-dashboard, monitoring, metrics-collection and hacktoberfest.

Folia appearing in the topics list is worth a second look if you run that fork, since Folia changes the threading model and a plugin that measures tick behaviour on Folia is doing something different from the same plugin on Paper.

Where UnifiedMetrics is the wrong choice

Four cases argue against it.

The first is a server where you cannot tolerate a plugin that observes everything. The events collector counts login, join, quit, chat and ping events, and the server collector reads plugin and player counts, on every platform and by default. On a large server that is per-player and per-message work in the hot path, and the low impact claim is asserted rather than benchmarked in the README.

The second is a proxy-only deployment with a real need for tick or world metrics. Those two collectors are marked Bukkit and Minestom only, and there is no workaround offered in the README for a Velocity operator who wants them.

The third is a requirement for a specific, auditable build. The newest tag is from 2023 and the line since then has been a development build. If your deployment process needs a released, immutable artifact, that is a blocker unless you build it yourself.

The alternative is to run a general purpose JVM exporter. A JVM metrics agent attached to the server process gives you memory, garbage collection, threads and CPU without a Minecraft plugin, and it works identically on every platform including ones this plugin does not support. The difference in approach is exactly what the plugin adds: the events collector, the server counts and especially the tick duration histogram, none of which a JVM agent can produce because they depend on knowing what the server is doing. If you only want to know whether the server is healthy, the JVM route is simpler. If you want to know whether players are joining and leaving, you need a plugin.

Editorial conclusion

UnifiedMetrics fits a Minecraft server operator who wants the same metrics and the same dashboard across Spigot, Fabric, Minestom, Velocity and BungeeCord, and who already has Prometheus or InfluxDB to receive them. It does not fit a server that has to run a specific, audited version, since the last tagged release is 0.3.8 from 2023 and the 0.3.x line has been a development build since. Build it with `./gradlew assemble -x signArchives`, or consume the `dev.cubxity.plugins:unifiedmetrics-api` artifact from Maven Central if you are writing your own collector rather than deploying the plugin.

Frequently asked questions

Official sources

1. Cubxity/UnifiedMetrics on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases