Jira's Java process starts, reaches for port 8080, finds another program already holding it, and gives up. Two commands tell you exactly who the squatter is.
Only one program can listen on a port at a time, and Jira's web connector wants 8080 by default. Port conflicts appear right after something else lands on the server: a second Atlassian tool, a test copy of Tomcat, a monitoring agent with a web dashboard, or even a leftover Jira process that never really died. The log line is always the same - java.net.BindException: Address already in use. This page shows how to identify the owner by PID, decide whether it or Jira should move, and make the change without breaking anything else.
Do not guess. The catalina log states this fault in plain words, and confirming it takes one minute. If the log instead shows a database or Java error, the port is innocent and this page is not your fix.
catalina log in the logs folder of the Jira install directoryBindException or Address already in usehttp-nio-8080Windows knows exactly which process owns every listening port. The PID - the process ID number - is the bridge between the network view and the process view.
netstat -ano | findstr :8080 and note the PID in the last column of the LISTENING linetasklist | findstr 7312 - replace 7312 with your PID - to see the program namejava.exe or Tomcat, it may be a zombie Jira process or a second Jira; if it is another product, that product got to the port firstBoth fixes work, but they are not equal. Stopping a stray process is cleanest when the squatter is a leftover or a test install nobody needs. Moving Jira's port is better when the other program is a real production tool - but remember that Jira's port lives inside every bookmark, every integration and the Base URL your users know.
server.xml in the conf folder of the Jira install directory, and change the Connector port from 8080 to a free port such as 8081netstat -ano | findstr :8081 commandOne special case deserves its own warning: sometimes the squatter is Jira itself. If a previous Jira process hung during shutdown, Windows may still hold the port while the service shows Stopped. Starting the service then fails against its own ghost. Ending the orphaned Java process from Task Manager, confirming the port is free, and then starting the service resolves it - and a server reboot clears it too, at the cost of downtime for everything else on the machine.
java.exe processes started around the time Jira last ranThe full Jira startup repair, step by step, with the exact screens and log lines shown live.
▶️ Watch Full VideoOpen server.xml in the conf folder of the Jira install directory and find the Connector element - its port attribute is the HTTP port, 8080 by default. Also check the address users browse to: if a proxy such as IIS or Nginx sits in front of Jira, users may connect on port 80 or 443 while Jira itself still listens on 8080 behind it.
Then the port was only one fault, or not the fault at all. Go back to the newest catalina log after this latest start attempt and read the first SEVERE error again - with the port fixed, the log will now show the next stage's problem, commonly the database connection or a Java mismatch. Startup faults reveal themselves one layer at a time; that is normal, not a sign you made it worse.
Yes, but each needs its own install directory, its own Jira home directory, its own database, and its own port. A test instance installed carelessly with the default port is one of the most common reasons a production Jira suddenly fails after working for months - the test instance simply started first.