'It was working yesterday' is the most useful sentence in troubleshooting - it means something specific changed. This checklist hunts that change instead of dismantling a healthy system.
A Jira that dies after an update, a plugin install, or a plain Windows restart is a different problem from a Jira that slowly decayed. Something in the last change is guilty, and random repairs only bury the evidence. This page runs the recovery in the right order: back up first, name what changed, then check the few things changes actually break - service settings, start order against the database, Java pointers, and incompatible plugins.
1 Back up - Jira home directory + database, as they are now
2 Name the change - update, plugin, restart, Java, password
3 Service - running? set to Automatic?
4 Database - fully started before Jira tried?
5 Logs - first SEVERE error of the first failed start
A broken Jira still contains every project, comment and attachment reference your organisation owns. Repairs attempted on the only copy are how 'Jira is down today' becomes 'Jira is gone'. Because Jira will not start, the backup is file-level - and that is fine.
dbconfig.xml, attachments, indexes and the logs you are about to rely onsetenv.bat and server.xml from the install directory too - your custom settings live thereAsk the question out loud and answer it honestly before touching anything. In office environments the change is rarely secret: Windows Update ran overnight, a JDK was upgraded for another tool, an admin installed a plugin, or the database password policy expired the Jira account. Each suspect has a different fix, and the logs will confirm which one you have.
Restarts break Jira in boring, fixable ways. The service may be Manual. The database may accept connections minutes after Jira has already given up. A temporary process may hold the port. None of these need a reinstall - they need the settings put right.
services.msc, confirm the Jira service is Automatic and the database service is toonetstat -ano | findstr :8080If the logs show Jira reaching the plugin stage and dying there - long lists of plugin errors, a startup check page that names a plugin - believe them. An incompatible plugin after a Jira update is a documented, ordinary failure, not a catastrophe. The recovery is to remove or disable the offending plugin's files from the Jira home directory's installed-plugins area while Jira is stopped, start Jira clean, and only then deal with the plugin's vendor for a compatible version. If the Jira upgrade itself failed halfway, do not upgrade again on top of it: the supported road back is your pre-upgrade backup - which is why Rule Zero exists, and why the next upgrade gets a backup before it, not after.
The full Jira startup repair, step by step, with the exact screens and log lines shown live.
▶️ Watch Full VideoA restart is itself a change: services come up in a new order. If Jira started before its database was ready, it failed once and stayed down. The service may also be set to Manual. Start the database, prove it works, then start Jira - and set the Jira service to Automatic (Delayed Start) so the database wins the race next time.
A failed upgrade cannot be rolled back by reinstalling the old version over it, because the upgrade may have already changed the database. The supported recovery is restoring the backup taken before the upgrade - database plus Jira home directory together - then running the older version against that restored pair. This is exactly why a pre-upgrade backup is not optional.
Yes. Stop the Jira service, then move the plugin's file out of the installed plugins folder inside the Jira home directory (keep it aside, do not delete it), and start Jira. If Jira starts cleanly, the diagnosis is confirmed. Then obtain the plugin version built for your Jira version from the vendor before reinstalling it.