FloQast Status Page

May 19, 2026 · resolved May 20

**Summary:** On May 19, 2026, some customers on our US database experienced "Something Went Wrong" errors when attempting to access the FloQast platform. Affected customers were able to restore access by clearing their browser cache. The issue was fully resolved on May 20. **Root Cause:** A recent update to how the platform routes login and authentication requests introduced a misconfiguration in the network path. Under the new routing, certain browser security checks received an unexpected redirect response, which browsers are required to reject per web standards. Once a browser encountered this error, it cached the failure, meaning subsequent requests by the same user continued to fail until the browser cache was cleared. **Immediate Resolution:** The network routing configuration was corrected so that authentication requests reach the intended destination without triggering the redirect. The fix prevents recurrence of the caching problem going forward. **Follow-up Actions:** Additional controls are being put in place to allow the team to respond more quickly to issues with future rollouts, limiting customer impact while investigations are underway. The production deployment pipeline is also being strengthened with additional safeguards to ensure rollback procedures work as expected when needed.

May 18, 2026 · resolved May 18

**Summary:** Between 10:23 AM PT on May 15, 2026, and 4:50 PM PT on May 18, 2026, customers on the APAC database were unable to upload Trial Balance and Chart of Accounts files via the FloQast Connect SFTP server. **Root Cause:** A software update to an internal file-processing component introduced a new configuration requirement that had not been applied to the APAC database environment. As a result, the service was unable to construct the correct address for its internal file handling system, causing all upload attempts to fail. **Immediate Resolution:** The missing configuration was identified and applied to the affected environment, restoring normal upload functionality. Successful file transfers were confirmed shortly thereafter. **Follow-up Actions:** The team is conducting a broader audit to ensure configuration standards are consistently applied across all service environments and databases. Additional safeguards are being added to the deployment process so that configuration requirements introduced by software updates are validated across all affected services before they reach production.

May 12, 2026 · resolved May 12

**Summary:** On May 12, 2026, between 10:46 AM PT and approximately 1:15 PT, the Request Agent feature was unavailable. Functionality was restored for customers on our US database at approximately 1:15 PT, for customers on our EU database at approximately 1:24 PT, and for customers on our APAC database by 1:55 PT. Customers were unable to create or view Requests, and customers were also unable to create Evidence Requests in Compliance Management. **Root Cause:** This incident was caused by an error introduced during a routine infrastructure update that resulted in certain services becoming misconfigured when deployed to production, making the Request Agent feature unavailable. **Immediate Resolution:** The misconfiguration was identified, and the affected services were restored to a known-good state, returning full functionality across all regions. **Follow-up Actions:** The deployment pipeline has been updated so that the affected class of services now always builds fresh from environment-specific configuration rather than reusing previously packaged artifacts, preventing this category of misconfiguration from reaching production. Traffic routing configuration is being audited across environments to ensure priority values are consistent and changes are validated before reaching production. The team is also accelerating the migration of affected legacy services to a more modern hosting model that eliminates this class of packaging issue entirely.

May 11, 2026 · resolved May 11

**Summary:** On May 11, 2026, between 3:08 PM and 3:48 PM PT, all customers using the US production environment were unable to log in or access the application. Customers on the EU and APAC databases were not affected. **Root Cause:** A recent deployment introduced a change to how the application constructs the web addresses used to communicate with its backend services. Due to a difference in how those addresses are formatted in the US environment compared to other regions, requests were being sent to an incorrect path, which prevented authentication and page access from completing successfully. **Immediate Resolution:** The address construction logic was corrected, and the fix was deployed, restoring full access for all affected customers shortly thereafter. **Follow-up Actions:** We are broadening automated test coverage to exercise environment-specific configuration more thoroughly, so this class of issue can be caught before reaching production. Additional monitoring and alerting are being added to detect access failures earlier. We are also working toward greater consistency in how service addresses are defined across our production environments to reduce the risk of environment-specific regressions going forward.

May 8, 2026 · resolved May 8

**Summary:** Beginning at approximately 12:50 PM PT on May 7th, customers using the AutoRec Matching module were unable to upload transaction files or sync data from NetSuite. Uploads failed without clear error messages, and NetSuite sync jobs appeared to stall without completing. Upload functionality was restored at 8:38 AM PT on May 8th, and NetSuite sync functionality was restored at approximately 1:40 PM PT. **Root Cause:** While resolving a separate platform issue, a routine redeployment of several background services caused two of them to load incompatible versions of a shared software component. **Immediate Resolution:** Both services were restored to their correct configurations, resolving file upload and NetSuite sync failures across all production regions. A backlog of jobs that had stalled during the incident was also cleared manually, allowing them to complete successfully. **Follow-up Actions:** The team is putting in place more rigorous validation steps around service redeployments to catch configuration mismatches earlier. Additional monitoring is being added to surface these issues faster if they occur.