A failed Jira writes hundreds of log lines. Only a handful matter, and they are never the ones at the top. Here is the reading method admins actually use.
Every Jira startup failure on this site - service, port, Java, database, memory - ends at the same place: the logs. The problem is not a lack of information; it is too much of it, in the wrong order. A dying Jira logs the real error first, then dozens of follow-on failures as each subsystem collapses in turn. Beginners read from the top and drown; the last error they read is usually a symptom. This page gives you the two files that matter, and the end-first method that finds the one error that actually stopped Jira.
Jira writes to several places, but startup diagnosis needs only two. Learn their homes once and you will never hunt again. Both are plain text - open them in Notepad or any editor, and use the file's modified time to be sure you are reading the attempt you care about.
logs folder of the Jira install directory, named with dates, like catalina.2026-10-25.log - they cover the Tomcat container: service start, port binding, Java-level failureslog folder inside the Jira home directory - it covers the application itself: database checks, plugin loading, startup checksThis is the whole technique, and it works because of how failures cascade. When one stage dies, everything that depended on it logs errors too - so the file fills with noise after the real error. Reading backwards puts the cause before the consequences.
SEVERE or ERROR block you meet - that is the earliest fatal error of this attemptCaused by lines and read the deepest one - that sentence, in plain language, is your fault: a login failed, a port is bound, a class version is wrongA few phrases cover most dead Jiras. Recognising them turns a wall of text into a diagnosis in one glance - and each maps to one fix, not five guesses.
BindException: Address already in use - the port is taken; find the owner with netstat -ano | findstr :8080Login failed for user or Access denied - database credentials in dbconfig.xml do not match the databaseCould not create the Java Virtual Machine - the heap requested cannot be reserved; check setenv.bat values against free RAMOutOfMemoryError: Java heap space - the heap is too small for the workload, or something is leakingUnsupportedClassVersionError - the Java running Jira is older than the code expects; a JAVA_HOME and version problemLogs are evidence, and repairs go better when evidence is not trampled. Restarting Jira ten times while guessing buries the original failure under ten new ones. Work like an investigator: one change, one start, one fresh read of the end of the log. If you must hand the problem to Atlassian support or a senior admin, that discipline - plus a zipped copy of both logs with the failure time noted - is exactly what they will ask for first.
The full Jira startup repair, step by step, with the exact screens and log lines shown live.
▶️ Watch Full VideoIn two places. The catalina logs are in the logs folder inside the Jira install directory. The atlassian-jira.log is in the log folder inside the Jira home directory - on a standard Windows install, under C:\Program Files\Atlassian\Application Data\Jira. Always check the file's modified time to make sure you are reading the latest start attempt.
Use your editor's search with intent: jump to the end first, then search backwards for SEVERE or ERROR, and under the first fatal block read the deepest Caused by line. Searching for one phrase at a time - BindException, Login failed, OutOfMemoryError - also works well. Never read a startup log from the top; the top is yesterday's healthy start.
It usually means the failure happened before Jira could write - the Java virtual machine never started, or the service could not launch it. Check the Windows Event Viewer (Application and System logs) at the failure time, and verify JAVA_HOME and the Java version next. Silence in Jira's own logs is itself a strong clue pointing at Java or the service layer.