# Sage X3 Syracuse Service Won't Start: Troubleshooting Guide > Source: https://netray.co/erp-help/sage-x3-syracuse-service-wont-start-troubleshooting > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer When Sage X3 users reach no login page, check the Syracuse Windows service and its dependencies in order: the MongoDB service that holds Syracuse configuration, the port and certificate Syracuse binds to, then the connection from Syracuse to the X3 runtime. Syracuse log files normally state which step failed, so read the log before restarting things repeatedly. ## Kind error ## System small-erp ## Erp Sage X3 ## Module Syracuse / Administration ## Query Sage X3 Syracuse service will not start ## Alternate Queries - Sage X3 cannot connect to runtime Syracuse - Sage X3 login page not loading port 8124 - Sage X3 Syracuse MongoDB not running - Sage X3 Syracuse certificate expired ## Applies To Sage X3 version 7 to 12 on Windows (Syracuse is a Node.js web server with a MongoDB repository); service names, folder paths and defaults differ by version and installer choices, so verify on your host ## Steps ### Work from the service outward **Items:** Open Services on the Syracuse host and find the Sage X3 Syracuse service (the name includes the instance name chosen at install). Note whether it is stopped, starting or running, and the error shown on a start attempt. Check the dependent database service. Syracuse stores its configuration (endpoints, users, sessions) in MongoDB, so a stopped or crashed MongoDB service stops Syracuse. Start MongoDB first, then Syracuse. Read the Syracuse log files under the installation's log folder, and the MongoDB log. Look for the first error after startup, such as port in use, cannot read certificate, or database connection refused. Confirm the port is free. Run netstat for the Syracuse port and see whether another process (a second instance, IIS, another web app) already binds it. Check the certificate if the instance uses HTTPS. An expired or replaced certificate, or a permission change on the key file, stops secure startup or makes browsers refuse the site. Check disk space on the drive that holds MongoDB data and logs. A full drive stops MongoDB and then Syracuse. Once Syracuse runs, log in to the administration page and test the endpoint's connection to the X3 runtime. A running web server with a failed runtime connection shows a login that then fails. After the fix, test with one user and one script call before announcing the system is back. ## Sections ### How the pieces depend on each other **Body:** Syracuse is the web tier. Behind it, there is a MongoDB repository for its own configuration, and the X3 runtime and database (SQL Server or Oracle) for business data. A user session needs all three. The symptom determines where to look: no page at all points to Syracuse or the port; a page that loads but rejects a login points to the repository or user setup; a login that works but a folder that will not open points to the runtime connection. Treat these as separate layers and test each in order instead of rebooting the whole stack. Rebooting can hide the cause and, if MongoDB was killed uncleanly, can add a recovery delay that looks like another failure. ### Ports, certificates and Windows changes **Body:** Windows updates, a new security product, a certificate renewal or a changed service account are the usual triggers for a service that worked yesterday. A service account whose password expired will fail to start with a logon failure in the Windows event log. A renewed certificate placed in the wrong store, or without the private key, produces start errors or browser trust warnings. Firewall rules matter for access, not for startup. If Syracuse is running on the host but users cannot reach it, test from the server itself first, then from a client, to separate a firewall or proxy problem from an application problem. If a reverse proxy sits in front, check its upstream and certificate too. **Code:** - netstat -ano | findstr :8124 sc query type= service state= all | findstr /i "syracuse mongo" Get-EventLog -LogName Application -Newest 30 -EntryType Error ### Runtime and database connection failures **Body:** If Syracuse is up and the user logs in but folders fail to open, test the runtime connection from the administration page: the endpoint definition holds the runtime host, port and folder. A changed hostname, a stopped X3 runtime service (the adxd daemon on the runtime host), or a database that is offline all show up here. Confirm that the X3 database is online and accepting connections before suspecting Syracuse. For repeated unexplained stops, look at memory and disk pressure on the host, Node process crashes recorded in the log, and MongoDB journal messages. Sizing is a real cause on small hosts that run Syracuse, MongoDB and the database engine together. ### Prevention **Body:** Monitor the services and the HTTPS port rather than waiting for users to report, and alert on certificate expiry at least a month ahead. Keep MongoDB backups of the Syracuse repository as part of your X3 backup, not only the business database, because restoring the database without the matching repository can leave endpoints and users missing. Document the service account, port, certificate location and endpoint settings in a runbook. Most prolonged outages are caused by one person knowing how the instance was installed. ## Pitfalls - Restarting the Syracuse service repeatedly without reading the log, which hides the first error. - Starting Syracuse before MongoDB is up. - Replacing a certificate without its private key or in the wrong store. - Letting the service account password expire, which stops the service on the next restart. - Backing up the X3 database but not the Syracuse repository. - Running all tiers on an undersized host and treating the resulting crashes as software bugs. ## Ai Angle An assistant can help with the diagnosis by reading log excerpts you paste in and mapping the first error to the layer it belongs to, using runbook text and vendor documentation indexed privately. Netray does not manage your X3 infrastructure. For monitoring, a custom build can ingest service and log events from your own systems on-prem and answer questions about them, with the underlying lines shown. ## Faq ### Why does Syracuse need MongoDB? **Answer:** Syracuse keeps its own configuration there, including endpoints, users, roles and sessions. If MongoDB is down, Syracuse cannot start or serve logins even though the X3 business database is fine. Start MongoDB first. ### The login page loads but I cannot open a folder. What now? **Answer:** That points to the runtime connection rather than Syracuse. Test the endpoint from the administration page, confirm the X3 runtime service and database are running, and check the hostname and port in the endpoint definition. ### How do I find out which process is using the Syracuse port? **Answer:** Run netstat with the process option for the port number, then look up the process ID in Task Manager or with tasklist. A second instance, IIS or another web app on the same port is the usual culprit. ### Do I need to back up MongoDB for X3? **Answer:** Yes. The Syracuse repository holds endpoints, users and settings, and a restore of only the business database can leave those missing. Follow Sage's documented backup procedure for your version and test a restore. ## Search terms Sage X3 Syracuse service, Sage X3 login page not loading, Sage X3 MongoDB, Syracuse certificate Sage X3, Sage X3 port 8124, Sage X3 runtime connection, Sage X3 troubleshooting, Sage X3 Syracuse logs, Sage X3 administration, Sage X3 server down --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json