Guides · Engineering

Did your plugin update break something? How to know in the first hours

How to tell within hours whether a new version of your Spigot, Paper or proxy plugin introduced a bug: errors per version, affected installs, logs and lag.

Updated 13 October 2026 · by Skilled · 4 min read

You ship an update on Friday evening. By Sunday there are three new one-star reviews, a dozen messages in your Discord and a thread titled "1.4.0 broke everything". The bug was there from the first hour. You just had no way to see it.

Most of what goes wrong after a release is visible long before anyone writes a review, if you look at the right numbers. This guide covers which ones, and how to read them without panicking over noise.

Why reports arrive late

Server owners rarely report bugs on the day they update. They notice something odd, assume it's their setup, try a restart, ask in a general channel and only then, if at all, report it. Many never report: they roll back or remove the plugin. By the time a report reaches you, the update has been on many servers for days.

So the signal has to come from the servers themselves.

Signal 1: new errors, by version

The most direct sign is an exception that didn't exist before the release. For that you need every exception from every server, grouped so that the same bug on a thousand servers is one issue, with the plugin version it was first seen in.

With PluginAnalytics, exceptions that go through your code are captured automatically. Each issue shows the version where it first appeared and the last one where it was seen, so a bug introduced in 1.4.0 says so. Issues that are new in the last two days are marked new.

Signal 2: how many installs it hits, not how many times

Raw counts mislead. One server stuck in a loop can throw the same exception 50,000 times in a day, while a bug that breaks a feature on 200 servers might throw it 400 times. Sorted by count, the first one looks like the emergency.

What tells you whether a release introduced a widespread problem is the number of installs affected: each server counted once, however often it repeats the error, and what share of the installs running that version it is. Open an issue and compare versions side by side:

An example, not real data.

That table reads instantly: 1.3.2 has a rare edge case, 1.4.0 broke something for almost half the servers that updated. The raw count could have said the opposite.

Signal 3: resolved bugs that come back

A fix that doesn't fix everything is the most frustrating kind of release. Mark an issue as resolved when you ship the fix. If it happens again on any server, it's marked regressed and you get a notification, instead of discovering it in a review that says "still broken".

Signal 4: logs that change after the release

Not every problem throws. A missing config key, a database that can't connect, an arena without spawn points: these are warnings in the log. When your plugin's own log lines are collected from every server and grouped by template (numbers become #), a new warning that appears on many servers after a release stands out, and you can filter logs by plugin version to compare before and after. Logs are part of the Pro and Premium plans.

Signal 5: did it get slower?

A release can be correct and still hurt servers. If your plugin's performance is sampled on every server and broken down by method and version, a new version that takes twice as long in a listener is obvious the same day. Server owners notice lag long before they find its cause, and they rarely blame the right plugin. Performance by method is part of the Premium plan.

Signal 6: do servers keep it?

The slowest signal, and the most honest one. If servers that install or update to the new version drop your plugin more often than before, something in the release hurts, even if nothing throws. Retention compares servers by the day or week they installed. It takes a few days to read, so use it to confirm, not to detect.

What to do when a release is broken

Once you know, the fix is only half of it. The other half is getting servers off the broken version:

• Ship the fix as a new version, even if it's one line, so update checkers see it.
• Warn the servers on the broken version. With update notices, servers below a version you mark as critical get a stronger message in the console and, if you want, admins see it in chat when they join. You set it from the dashboard, without another release.
• Say what happened in the update post. Owners forgive bugs much more easily than silence.

A release checklist

1. Before the release, mark the issues you fixed as resolved.
2. In the first hours, watch for issues marked new, and check the installs affected on the new version.
3. After a day, compare the error share of the new version with the previous one, and scan the logs for new warnings.
4. If something is widespread, fix it, publish, and set the broken version as critical in update notices.
5. After a week, check retention for servers that updated.

None of this needs a single bug report. The servers already know; you just need to listen. Error tracking and the errors guide cover the setup, which is one line in onEnable.

More guides