Guides · Growth
Why servers uninstall your Minecraft plugin in the first day
Many installs of a plugin are gone within a day. How to measure install retention, find out what sends owners away, and fix the first run.
A server owner downloads your plugin, drops it in the plugins folder and restarts. Ten minutes later it's gone. They didn't leave a review, didn't open a ticket, didn't ask in your Discord. From your side it's one more download, the same as an owner who will run your plugin for three years.
Downloads count the first step. Whether your plugin grows depends on the second one: how many of those installs are still running a day, a week, a month later. And for many plugins, the biggest loss happens in the first day.
Measure it first: install retention
Retention groups servers by the day or week they installed your plugin, and shows the share that's still running it in each period after. A typical shape: a sharp drop on day one, a slower slide over the first week, then a flat line of servers that kept it.
The flat line is your real audience. The first-day drop is where the work is, because those owners were interested enough to install and something sent them away within minutes.
With PluginAnalytics, retention needs no code: a server counts as installed when it first sends data, and as retained in each later day or week it still does. The Overview sums it up as installs still running after 1, 7 and 30 days, and the Retention page shows each cohort, up to 13 periods. Retention is part of the Pro and Premium plans. Retention
Two things make the number honest:
- Compare cohorts, not one day. A cohort from a week when a popular server list featured you will look different from a quiet week. Look at the trend across several.
- Test servers count too. Developers and owners test on local servers that are deleted the same day. Some first-day loss is normal and never goes away. What matters is whether it changes after you change something.
Why owners give up in the first hour
When an install disappears within a day, the owner usually hit one of a handful of walls.
It didn't load. A missing dependency, the wrong Java version, a Minecraft version you don't support. The console shows a red stack trace at startup, the owner doesn't read it, and the plugin is removed.
It loaded but did nothing visible. The plugin needs an arena, a region or a database before anything happens, and nothing tells the owner. They type the plugin's name, see a list of 30 subcommands and close it.
The defaults were wrong for them. Messages in a language or style that doesn't fit, a feature on by default that breaks something else, a world name that doesn't exist on their server.
It threw errors right away. An exception on the first player join is enough to get removed, even if it's harmless.
It didn't do what they expected. Your listing promised one thing and the plugin does another. This one is a listing problem more than a code problem.
Each of these leaves a trace you can look for.
Finding which wall it is
Errors from new installs. Exceptions that go through your code are captured from every server, grouped by type and stack, on every plan. Look first at errors thrown at startup or on the first player join: every new install hits them. They're often a missing file, a null config value or a dependency you assumed. Errors
Missing dependencies. Every plugin in your depend and softdepend lists is reported as installed or missing. If a large share of servers is missing a soft dependency your plugin quietly needs for its main feature, that's your first-day drop. This shows next to the config options, which are part of the Pro and Premium plans. Dependencies
Versions. The Servers page breaks servers down by Minecraft version, Java version and server software. If your listing claims a version that almost none of your active servers run, try your plugin on a fresh server with it: a startup error there sends every install on that version away on day one. Which versions to support
Setup that never finishes. Track your setup milestones as server events (no player), and build a server funnel that starts at Plugin installed:
// In your setup command handlers
analytics.track("arena_created");
analytics.track("arena_enabled");
If most installs never create an arena, owners don't find out how, or it's too much work. Funnels are part of the Pro and Premium plans. Server funnels
Defaults nobody keeps. Config usage shows, for every plain option in your config.yml, the share of servers that changed it from your default. Options most servers change on the first day are defaults that don't fit. Which config options do owners change?
Fixing the first run
Once you know the wall, the fixes are rarely big.
Fail clearly. If something your plugin needs is missing, say so in one line at startup, with what to do: Vault was not found. Install Vault and an economy plugin, or set economy: none in config.yml. A clear line beats a stack trace every time.
Work out of the box. Ship defaults that do something on a fresh server: a sample arena, a default kit, a feature that works without a database. Owners decide in minutes whether a plugin works, and the first thing they see should be it working.
Tell them the next step. On the first start, log one short message that says what to do next, and show it in chat to the first operator who joins: the one command that sets things up, or a link to a short guide. One step, not the whole manual.
Fix first-run errors before anything else. An exception on a fresh install costs more than the same exception on a server that has run your plugin for a year. The second owner knows your plugin is worth it; the first one doesn't yet.
Make the listing match the plugin. If installs disappear without errors or missing dependencies, read your resource page again as a stranger would, and compare it with what the plugin does on a fresh server. Resource page template
Let owners tell you
Some of what sends owners away never shows up in data. On Spigot, Paper and Purpur, the SDK adds /<plugin> report and suggest to your plugin's command, so an owner who hits a problem can tell you in one line from the game, and bug reports arrive with your plugin's errors and log lines from the minutes before. Bug reports & ideas
Check after each change
Change one thing at a time, then watch the cohorts that installed after it. If day-one retention goes up, keep it. Retention takes days to read, so it confirms rather than detects: pair it with errors from new installs, which show up the same day.
A plugin that keeps two installs in three instead of one in three grows twice as fast with the same downloads. That's usually cheaper than getting more downloads. More downloads on SpigotMC
More guides
Which config options do server owners actually change?
Your config.yml has dozens of options. Find out which ones server owners actually change, fix the defaults everyone changes, and read nothing private.
4 min readProductWhere do players quit your minigame? Funnels for Minecraft plugins
Players join, find the game, finish a round, come back, or don't. A funnel shows which step loses the most players, so you fix that one first.
3 min read