--- service: "Lucidworks" status: "up" reports_last_hour: 0 reports_last_12_hours: 0 baseline_reports_per_hour: 0 checked_at: "2026-11-01T06:58:51.973Z" url: "https://instatus.com/now/lucidworks.com" official_status_page: "https://status.lucidworks.com" website: "https://lucidworks.com" --- # Is Lucidworks down? No, it's up. 0 reports in the last hour. ## Official updates - **Connected Search and AI Agent Service Disruption** (RESOLVED, 2026-10-27T14:37:43.000Z): ## Summary On October 27, 2026, between 02:51 UTC and 17:29 UTC, Connected Search and Agent Studio agents in the Lucidworks production environment began returning intermittent errors. Any query request could potentially return a HTTP 500 error after waiting up to two minutes for a response. Other Lucidworks Platform services, including embedding models, LLM access, Commerce Studio, and the Lucidworks Platform UI, were not affected. Lucidworks was alerted at 03:12 UTC and began remediation efforts. The incident was resolved at 21:30 UTC. ## Root Cause The first window of disruption began at 02:51 UTC. The successful-response count from our search backend, hosted by a third-party provider, dropped to zero, and the search service stopped answering queries. Lucidworks restarted the services that were reporting unsuccessful search connections, which restored normal operation by 03:33 UTC. The second window began at 13:50 UTC, with smaller bursts of errors through 17:30 UTC. Lucidworks restarted services again and re-engaged our incident response procedures. During this window, we turned off extraneous search query services across the Lucidworks Platform, updated the third-party HTTP client settings to the provider's current recommendations, and added explicit timeouts and a larger connection pool. No errors were observed after these changes were put into effect at 17:29 UTC, and the incident was resolved at 21:30 UTC. The query service connection to the third-party search backend used default connect, read, and connection-wait timeouts, and the connection pool was small. When a connection stalled or was closed without a response, the request waited indefinitely, holding a pool slot and a request thread until the caller timed out after two minutes. With enough stalled connections, the service stopped serving search requests until it was restarted. The default timeouts turned connection problems into a service outage instead of a few quickly failing requests. In the second outage window, the third-party provider confirmed that the disruption coincided with a platform upgrade that restarted two of its container nodes. The provider recommended the changes to connection timeouts that we were already planning to add to our service. However, the behaviour was not limited to the confirmed upgrade window. In the first window, the third party reported no restarts, errors, or changes in request rate on its side, and the trigger for the stalled connections had not yet been identified. After the fixes were deployed, three connection attempts \(at 21:05 UTC and twice at 21:42 UTC\) received no answer to the TLS handshake. In each case, the new connection timeout ended the attempt after 2 seconds, and the retry on a new connection succeeded. Over the same period, all search requests returned successfully, with a median \(p50\) latency of 44 ms, validating our connection timeout fixes.The cause of the remaining intermittent issues on our search backend continues to be investigated by our provider. ## Lucidworks Actions Lucidworks will take the following actions as a result of this incident: * Add a scheduled check to our third-party provider's current recommendations for HTTP client settings to their service to proactively capture new suggestions for our query services * Update our tracked metrics for our services to monitor for recurrences of this particular issue * Ensure that adding additional infrastructure does not increase the connection load to our regionalized search services * Work with our third-party provider to identify what stalled the connections in the first window, and why some TLS handshakes still go unanswered outside the confirmed upgrade window ## Recommended Client Actions There are no recommended client actions as a result of this incident. - **Connected Search Service Disruption** (RESOLVED, 2026-10-27T02:51:30.000Z): This incident is now fully resolved and all systems have returned to normal operations. Lucidworks services and software are operating normally with no remaining disruption, and there is no remaining direct customer impact to end users. ## Lucidworks outage FAQ ### Is Lucidworks down right now? No, it's up. 0 reports in the last hour. ### Is Lucidworks down for everyone or just me? It looks like it's just you. Reports for Lucidworks are at their usual level, so try reloading, checking your connection, or signing out and back in. ### What problems are people reporting with Lucidworks? Nobody has said what's broken with Lucidworks in the last hour. If something isn't working for you, pick it above so others can see. ### When was the last Lucidworks outage? Reports for Lucidworks haven't spiked in the last 30 days. ### Does Lucidworks have a status page? Yes. Lucidworks posts updates on its official status page, which currently says operational. [Go to status page](https://status.lucidworks.com/) ### What can I do if Lucidworks isn't working? Check this page and Lucidworks's status page for updates, and wait a few minutes before trying again. Skip reinstalling: if it's an outage, the fix is on their side. ### How do I report a Lucidworks problem? Hit “I have an issue too” at the top of this page and pick what's broken. Your report shows on the live chart within a minute, and you can leave a comment to tell others what you're seeing. ### How does Instatus Now know? We combine reports from people on this page with Lucidworks's official status page, which we check every minute.