Sage X3 Syracuse Service Won't Start: Troubleshooting Guide
Sage X3 Syracuse service will not start
Also searched as
- 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
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.
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
Work from the service outward
- 1Open 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.
- 2Check 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.
- 3Read 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.
- 4Confirm 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.
- 5Check 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.
- 6Check disk space on the drive that holds MongoDB data and logs. A full drive stops MongoDB and then Syracuse.
- 7Once 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.
- 8After the fix, test with one user and one script call before announcing the system is back.
How the pieces depend on each other
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
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.
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
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Why does Syracuse need MongoDB?
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?
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?
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?
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.
Related
Sage X3 REST API: Reading Sales Orders Through Syracuse
Sage X3 (version 7 and later) exposes data through Syracuse at a URL of the form /api1/x3/erp/ENDPOINT/REPRESENTATION, where the endpoint is the folder and the representation is a published object such as SORDER. A GET with credentials returns JSON, and you filter with a where clause and page with count and a link to the next page. Your integration user needs the right Syracuse and X3 rights for that representation.
How-toHow to Run a Physical Inventory Count in Sage X3
Sage X3 physical counts run through Stock > Counts: create a count session scoped to a site, category, or zone, generate the count sheet to freeze theoretical quantities, enter counted quantities, review the variance report, then validate to post stock and valuation adjustments. Blocking movements against the counted locations during the window keeps the variance meaningful.
Error fixFix Sage 100 SOTAMAS90 ODBC Connection Errors
Most Sage 100 ODBC failures are one of four things: the DSN was created in the wrong 32-bit or 64-bit ODBC administrator for the tool you use, the DSN path or company code is wrong, the Windows account cannot read the MAS90 folder, or the Sage 100 user lacks external access. Recreate the DSN in the matching administrator and test with the driver's own Test button before blaming Excel or Power BI.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
How-toHow to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
AI for ERPAI for Sage X3, Grounded in Your Own Ledgers and Stock Data
Add AI to Sage X3 finance and stock data without exporting it to a public model. On-prem and private-cloud LLMs for Sage X3 in the UK and France.
Stuck on Sage X3?
Talk to engineers who work inside Sage X3 every week, and who build private AI that answers these questions from your own ERP data.