FloQast Outage History

Started Oct 15, 2026, 08:44 PM UTC· resolved Oct 15, 2026, 10:13 PM UTC

1. investigating Oct 15, 2026, 08:44 PM UTC

   We are currently investigating the issue.

2. monitoring Oct 15, 2026, 09:51 PM UTC

   A fix has been implemented and we are monitoring results.

3. resolved Oct 15, 2026, 10:13 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 02, 2026, 03:46 PM UTC· resolved Jun 02, 2026, 05:48 PM UTC

1. investigating Jun 02, 2026, 03:46 PM UTC

   We are currently investigating reports of errors when refreshing reconciliations and uploading files for customers using our Egnyte integration.

2. identified Jun 02, 2026, 04:09 PM UTC

   The issue has been identified and a fix is being implemented.

3. resolved Jun 02, 2026, 05:48 PM UTC

   Jun 2, 10:48 PDT Resolved - We have released a fix for this issue, and customers using Egnyte should no longer be experiencing these errors. We are continuing to monitor to ensure stability, and a Root Cause Analysis will be shared here when available. Jun 2, 09:09 PDT Identified - The issue has been identified and a fix is being implemented. Jun 2, 08:46 PDT Investigating - We are currently investigating reports of errors when refreshing reconciliations and uploading files for customers using our Egnyte integration.

4. resolved Jun 02, 2026, 05:48 PM UTC

   We have released a fix for this issue, and customers using Egnyte should no longer be experiencing these errors. We are continuing to monitor to ensure stability, and a Root Cause Analysis will be shared here when available.

Read the full incident report →

Started May 19, 2026, 08:18 PM UTC· resolved May 20, 2026, 07:42 PM UTC

1. investigating May 19, 2026, 08:18 PM UTC

   We are currently investigating reports of "Something Went Wrong" errors when loading pages in the application. For any affected customers, clearing your web browser's cache should allow you to access the application while our engineers address the underlying issue.

2. identified May 19, 2026, 08:31 PM UTC

   We have identified the cause of the issue and are working on a fix.

3. resolved May 20, 2026, 07:42 PM UTC

   May 20, 12:42 PDT Resolved - A fix has been released for this issue, and customers should no longer receive these "Something Went Wrong" errors. If you continue to receive the error, refreshing your browser will resolve it. We will continue to monitor, and a Root Cause Analysis will be posted here once available. May 19, 13:31 PDT Identified - We have identified the cause of the issue and are working on a fix. May 19, 13:18 PDT Investigating - We are currently investigating reports of "Something Went Wrong" errors when loading pages in the application. For any affected customers, clearing your web browser's cache should allow you to access the application while our engineers address the underlying issue.

4. resolved May 20, 2026, 07:42 PM UTC

   A fix has been released for this issue, and customers should no longer receive these "Something Went Wrong" errors. If you continue to receive the error, refreshing your browser will resolve it. We will continue to monitor, and a Root Cause Analysis will be posted here once available.

5. postmortem May 29, 2026, 06:01 PM UTC

   **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.

Read the full incident report →

Started May 18, 2026, 10:56 PM UTC· resolved May 18, 2026, 11:47 PM UTC

1. investigating May 18, 2026, 10:56 PM UTC

   We are currently investigating reports of Trial Balance files not being successfully processed after being sent via the FloQast Connect SFTP server for customers on our APAC database.

2. resolved May 18, 2026, 11:47 PM UTC

   May 18, 16:47 PDT Resolved - We have released a fix for this issue, and Trial Balances uploaded via the FloQast Connect SFTP server are now being successfully processed again. We will continue to monitor and will share a Root Cause Analysis here when it is available. May 18, 15:56 PDT Investigating - We are currently investigating reports of Trial Balance files not being successfully processed after being sent via the FloQast Connect SFTP server for customers on our APAC database.

3. resolved May 18, 2026, 11:47 PM UTC

   We have released a fix for this issue, and Trial Balances uploaded via the FloQast Connect SFTP server are now being successfully processed again. We will continue to monitor and will share a Root Cause Analysis here when it is available.

4. postmortem May 20, 2026, 10:53 PM UTC

   **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.

Read the full incident report →

Started May 12, 2026, 07:13 PM UTC· resolved May 12, 2026, 08:59 PM UTC

1. investigating May 12, 2026, 07:13 PM UTC

   We are currently investigating an issue affecting Request Agent. Users attempting to access the Request Agent dashboard page may find the page loading endlessly.

2. investigating May 12, 2026, 07:21 PM UTC

   We are continuing to investigate this issue.

3. identified May 12, 2026, 07:39 PM UTC

   The issue has been identified and a fix is being implemented.

4. monitoring May 12, 2026, 08:49 PM UTC

   A fix has been applied to the US and EU databases and both are operating normally. We are continuing to work on restoring full functionality for the AU database. We will provide a further update once AU has been resolved.

5. resolved May 12, 2026, 08:59 PM UTC

   May 12, 13:59 PDT Resolved - This incident has been resolved. May 12, 13:49 PDT Monitoring - A fix has been applied to the US and EU databases and both are operating normally. We are continuing to work on restoring full functionality for the AU database. We will provide a further update once AU has been resolved. May 12, 12:39 PDT Identified - The issue has been identified and a fix is being implemented. May 12, 12:21 PDT Update - We are continuing to investigate this issue. May 12, 12:13 PDT Investigating - We are currently investigating an issue affecting Request Agent. Users attempting to access the Request Agent dashboard page may find the page loading endlessly.

6. resolved May 12, 2026, 08:59 PM UTC

   This incident has been resolved.

7. postmortem May 14, 2026, 09:50 PM UTC

   **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.

Read the full incident report →

Started May 11, 2026, 10:27 PM UTC· resolved May 11, 2026, 11:27 PM UTC

1. investigating May 11, 2026, 10:27 PM UTC

   We are aware of an issue causing an "Something Went Wrong" error for users attempting to access FloQast. Users may be unable to load the application or see an unexpected error on login. Our engineering team has been alerted and is actively investigating.

2. investigating May 11, 2026, 10:31 PM UTC

   We are continuing to investigate this issue.

3. monitoring May 11, 2026, 10:52 PM UTC

   A fix has been deployed for the issue affecting US customers. We are actively monitoring to confirm full stability.

4. monitoring May 11, 2026, 11:09 PM UTC

   We are continuing to monitor for any further issues.

5. resolved May 11, 2026, 11:27 PM UTC

   May 11, 16:27 PDT Resolved - This incident has been fully resolved. US customers can access FloQast as normal. A Root Cause Analysis will be published on this page shortly. We apologize for the disruption and thank you for your patience. May 11, 16:09 PDT Update - We are continuing to monitor for any further issues. May 11, 15:52 PDT Monitoring - A fix has been deployed for the issue affecting US customers. We are actively monitoring to confirm full stability. May 11, 15:31 PDT Update - We are continuing to investigate this issue. We have identified that this issue is isolated to our US region. Customers in the AU and EU regions have been confirmed as fully operational. May 11, 15:27 PDT Investigating - We are aware of an issue causing an "Something Went Wrong" error for users attempting to access FloQast. Users may be unable to load the application or see an unexpected error on login. Our engineering team has been alerted and is actively investigating.

6. resolved May 11, 2026, 11:27 PM UTC

   This incident has been fully resolved. US customers can access FloQast as normal. A Root Cause Analysis will be published on this page shortly. We apologize for the disruption and thank you for your patience.

7. postmortem May 14, 2026, 09:46 PM UTC

   **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.

Read the full incident report →

Started May 08, 2026, 03:25 PM UTC· resolved May 08, 2026, 08:48 PM UTC

1. investigating May 08, 2026, 03:25 PM UTC

   We are currently investigating an issue affecting AutoRec Matching. Users are able to upload transaction files successfully, however uploaded transactions are not appearing for matching. Additionally, clients with NetSuite connected accounts are experiencing failures when pulling transactions or 'user is currently matching' messages. We are actively investigating and will provide updates as they become available.

2. investigating May 08, 2026, 03:25 PM UTC

   We are continuing to investigate this issue.

3. resolved May 08, 2026, 08:48 PM UTC

   May 8, 13:48 PDT Resolved - The issue affecting transaction syncing has been resolved. Transactions should now be pulling in as expected for all connected clients. If you continue to experience any issues, please contact our support team. May 8, 08:25 PDT Update - We are continuing to investigate this issue. May 8, 08:25 PDT Investigating - We are currently investigating an issue affecting AutoRec Matching. Users are able to upload transaction files successfully, however uploaded transactions are not appearing for matching. Additionally, clients with NetSuite connected accounts are experiencing failures when pulling transactions or 'user is currently matching' messages. We are actively investigating and will provide updates as they become available.

4. resolved May 08, 2026, 08:48 PM UTC

   The issue affecting transaction syncing has been resolved. Transactions should now be pulling in as expected for all connected clients. If you continue to experience any issues, please contact our support team.

5. postmortem May 15, 2026, 10:22 PM UTC

   **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.

Read the full incident report →

Started May 07, 2026, 11:20 PM UTC· resolved May 08, 2026, 12:58 AM UTC

1. investigating May 07, 2026, 11:20 PM UTC

   We are currently investigating reports of notifications tied to Review Notes not being received

2. resolved May 08, 2026, 12:58 AM UTC

   May 7, 17:58 PDT Resolved - The fix for this issue has been released. Users may experience a brief delay as the backlog of queued notifications is processed. We are continuing to monitor the situation and will share a Root Cause Analysis here when available. May 7, 16:20 PDT Investigating - We are currently investigating reports of notifications tied to Review Notes not being received

3. resolved May 08, 2026, 12:58 AM UTC

   The fix for this issue has been released. Users may experience a brief delay as the backlog of queued notifications is processed. We are continuing to monitor the situation and will share a Root Cause Analysis here when available.

Read the full incident report →

Started May 07, 2026, 02:28 PM UTC· resolved May 07, 2026, 11:18 PM UTC

1. investigating May 07, 2026, 02:28 PM UTC

   We are currently investigating an issue where various functions within the FloQast application are erroring out, showing either a Lambda error or a Runtime error. This is being treated with the highest priority

2. identified May 07, 2026, 04:01 PM UTC

   The issue has been identified and a fix is being implemented.

3. identified May 07, 2026, 04:32 PM UTC

   The fix is currently being applied in parallel to all FloQast environments. We expect the full resolution to be in place very soon.

4. monitoring May 07, 2026, 06:23 PM UTC

   The fix has been initiated, and we are monitoring the results. We are aware of some errors still occurring due to warm lambdas which have not fully finished restarting yet. If a service is used and a lambda that has not been fully restarted yet is invoked, an in-app error may still occur.

5. resolved May 07, 2026, 11:18 PM UTC

   May 7, 16:18 PDT Resolved - The fix for this incident has finished deploying. A full RCA will be shared in this posting as soon as it is available. May 7, 11:23 PDT Monitoring - The fix has been initiated, and we are monitoring the results. We are aware of some errors still occurring due to warm lambdas which have not fully finished restarting yet. If a service is used and a lambda that has not been fully restarted yet is invoked, an in-app error may still occur. May 7, 09:32 PDT Update - The fix is currently being applied in parallel to all FloQast environments. We expect the full resolution to be in place very soon. May 7, 09:01 PDT Identified - The issue has been identified and a fix is being implemented. May 7, 07:28 PDT Investigating - We are currently investigating an issue where various functions within the FloQast application are erroring out, showing either a Lambda error or a Runtime error. This is being treated with the highest priority

6. resolved May 07, 2026, 11:18 PM UTC

   The fix for this incident has finished deploying. A full RCA will be shared in this posting as soon as it is available.

7. postmortem May 14, 2026, 10:02 PM UTC

   **Summary:** On May 7, 2026, from approximately 07:15 AM to 05:21 PM PT, customers across all regions experienced failures in automated workflows and email notifications within FloQast, resulting in jobs failing to execute as expected. **Root Cause:** A routine update from our cloud infrastructure provider changed how certain internal network traffic was handled. A prior update within our platform had not been fully applied across all parts of our environment, which created a conflict with the provider's change. Affected workflows failed immediately rather than completing normally. **Immediate Resolution:** The infrastructure update was rolled back to a prior stable configuration, and a process was run to fully refresh the affected workflows across all regions. All three regions were subsequently returned to normal operation. **Follow-up Actions:** We are taking several steps to strengthen our resilience to infrastructure changes of this kind. Going forward, updates from our cloud provider will be validated in a dedicated test environment before reaching production, giving us earlier visibility into any compatibility issues. We are also enhancing our internal monitoring to provide greater coverage across our infrastructure, and we are improving how we receive and act on cloud provider advisories so our engineering team can respond proactively to changes that may affect our environment.

Read the full incident report →

Started May 05, 2026, 03:53 PM UTC· resolved May 05, 2026, 08:04 PM UTC

1. investigating May 05, 2026, 03:53 PM UTC

   We are currently investigating reports of errors navigating the Single Workflow Dashboard. Users may see an error message when navigating between the Overview, Timeline, and Entities sections. The All Workflows Dashboard is not affected. We will post an update here as soon as we have more information.

2. identified May 05, 2026, 04:33 PM UTC

   We have identified the cause of the issue and are working on a fix. Users may still see the error when navigating between the Overview, Timeline, and Entities sections of the Single Workflow Dashboard. Closing the error will allow the page to load.

3. resolved May 05, 2026, 08:04 PM UTC

   May 5, 13:04 PDT Resolved - The fix for this issue has been released, and users should no longer be receiving errors when navigating the Single Workflow Dashboard. We are continuing to monitor performance, and a Root Cause Analysis will be shared here when it is available. May 5, 09:33 PDT Identified - We have identified the cause of the issue and are working on a fix. Users may still see the error when navigating between the Overview, Timeline, and Entities sections of the Single Workflow Dashboard. Closing the error will allow the page to load. May 5, 08:53 PDT Investigating - We are currently investigating reports of errors navigating the Single Workflow Dashboard. Users may see an error message when navigating between the Overview, Timeline, and Entities sections. After closing out of the error, the page should load as expected. The All Workflows Dashboard is not affected. We will post an update here as soon as we have more information.

4. resolved May 05, 2026, 08:04 PM UTC

   The fix for this issue has been released, and users should no longer be receiving errors when navigating the Single Workflow Dashboard. We are continuing to monitor performance, and a Root Cause Analysis will be shared here when it is available.

5. postmortem May 08, 2026, 07:07 PM UTC

   **Summary:** On May 5, 2026, customers navigating between tabs on the Single Workflow Dashboard encountered an error modal displaying "Something Went Wrong." While the underlying dashboard data continued to load normally in the background, the error modal obscured the experience for customers using that view. **Root Cause:** A recent update to the dashboard introduced a timing conflict in how the system managed temporary data storage during tab navigation. When customers switched between tabs, the system was clearing an internal data cache before a background process had finished using it, which triggered an error. The issue was most pronounced for customers on slower network connections, where the timing gap was more likely to occur. **Immediate Resolution:** The update that introduced the timing conflict was reverted, restoring the proper sequence of operations. **Follow-up Actions:** Test coverage is being expanded to test rapid navigation scenarios on the Single Workflow Dashboard to catch this class of issue before it reaches production. The underlying dashboard improvement that was reverted will be re-implemented with a safer approach before being reintroduced.

Read the full incident report →

Started May 01, 2026, 05:57 PM UTC· resolved May 01, 2026, 07:18 PM UTC

1. investigating May 01, 2026, 05:57 PM UTC

   We are investigating reports of an error when opening reconciliations from the Dashboard's Timeline view. In the meantime, reconciliations can be accessed directly via the Reconciliations and Folders tabs.

2. identified May 01, 2026, 06:14 PM UTC

   We have identified the cause of the issue and are working on a fix.

3. resolved May 01, 2026, 07:18 PM UTC

   A fix has been deployed, and reconciliations can now be opened from the Dashboard Timeline view without error. Thank you for your patience while our team investigated. A Root Cause Analysis will be shared here when available.

Read the full incident report →

Started Apr 20, 2026, 09:26 PM UTC· resolved Apr 23, 2026, 10:16 PM UTC

1. investigating Apr 23, 2026, 05:21 PM UTC

   We are investigating an issue where changes made through the All Entities Reconciliation Template are appearing in Admin Settings but not syncing to the Reconciliations tab. Please note that the Checklist is unaffected. As a temporary workaround, navigating to the Individual Reconciliation Settings page for a specific entity and clicking Save will apply any updates to that entity.

2. identified Apr 23, 2026, 07:41 PM UTC

   We have identified the cause of the issue and are working on a fix.

3. resolved Apr 23, 2026, 10:16 PM UTC

   Apr 23, 15:16 PDT Resolved - We have successfully deployed a fix and confirmed that changes made through the All Entities Reconciliation Template are now syncing correctly to the Reconciliations tab. A formal Root Cause Analysis (RCA) will be shared here once it is available. If there are any recent changes made via the All Entities Reconciliation Template that you do not see applied, re-applying the template should resolve the issue. Apr 23, 12:41 PDT Identified - We have identified the cause of the issue and are working on a fix. Apr 20, 14:26 PDT Investigating - We are investigating an issue where changes made through the All Entities Reconciliation Template are appearing in Admin Settings but not syncing to the Reconciliations tab. Please note that the Checklist is unaffected. As a temporary workaround, navigating to the Individual Reconciliation Settings page for a specific entity and clicking Save will apply any updates to that entity.

4. resolved Apr 23, 2026, 10:16 PM UTC

   We have successfully deployed a fix and confirmed that changes made through the All Entities Reconciliation Template are now syncing correctly to the Reconciliations tab. A formal Root Cause Analysis (RCA) will be shared here once it is available. If there are any recent changes made via the All Entities Reconciliation Template that you do not see applied, re-applying the template should resolve the issue.

5. postmortem Apr 24, 2026, 08:09 PM UTC

   **Summary:** Customers using Reconciliations experienced an issue where changes made via the All Entities template were saved in settings but failed to apply to individual periods. This resulted in template updates not being reflected across the application and a lack of email notifications for these bulk updates. **Root Cause:** A standard infrastructure upgrade changed how internal system information was passed between background services. This caused a critical communication failure that prevented the automated workflow from distributing template changes to the appropriate records, which occurred without surfacing an error message to the user. **Immediate Resolution:** Engineering teams implemented a multi-layered fix that restored the necessary system context and updated the underlying software dependencies. After rigorous testing across multiple environments to ensure full functionality and the restoration of automated notifications, the fix was deployed to all customers. **Follow-up Actions:** To prevent a recurrence, the team is enhancing end-to-end regression testing for infrastructure changes and improving monitoring to ensure visibility into background service health. Additionally, system alerts are being updated to provide immediate notification of failures in automated workflows, and internal deployment checklists are being refined to ensure consistent dependency management during platform upgrades. **Recommended Customer Action: Any customers who made Reconciliation updates via the All Entities Reconciliation Template between 2:26 PM PT on April 20 and 3:16 PM PT on April 23 should re-apply their reconciliation templates to ensure the changes are properly applied.**

Read the full incident report →

Started Apr 07, 2026, 08:00 PM UTC· resolved Apr 08, 2026, 02:55 PM UTC

1. investigating Apr 08, 2026, 12:52 PM UTC

   We are currently investigating this issue.

2. monitoring Apr 08, 2026, 01:35 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Apr 08, 2026, 02:55 PM UTC

   Apr 8, 07:55 PDT Resolved - This incident has been resolved. Apr 8, 06:35 PDT Monitoring - A fix has been implemented and we are monitoring the results. Apr 7, 13:00 PDT Investigating - We are currently investigating this issue.

4. resolved Apr 08, 2026, 02:55 PM UTC

   This incident has been resolved.

5. postmortem Apr 14, 2026, 07:30 PM UTC

   **Summary:** Clients experienced failures when attempting to push files through FloQast's SFTP integration. Automated file processing was interrupted across all production regions. **Root Cause:** A recent update to FloQast's file processing pipeline introduced a dependency on a new configuration that had been validated in a test environment but had not yet been applied to production. When the updated code was deployed to production, the underlying configuration it required was not in place, causing the file routing service to fail on startup. **Immediate Resolution:** Engineering teams identified the missing configuration and applied it across all production regions. **Follow-up Actions:** The team is implementing cross-repository deployment safeguards to ensure that when code changes and their corresponding infrastructure configurations are developed together, both are verified as deployed to production before either is considered complete. This will prevent scenarios where tightly coupled changes across different parts of the system can become inadvertently separated during the release process.

Read the full incident report →

Started Apr 07, 2026, 07:15 AM UTC· resolved Apr 07, 2026, 04:35 PM UTC

1. identified Apr 07, 2026, 02:30 PM UTC

   The issue has been identified and a fix is being implemented.

2. monitoring Apr 07, 2026, 03:20 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Apr 07, 2026, 04:35 PM UTC

   Apr 7, 09:35 PDT Resolved - This incident has been resolved. Apr 7, 08:20 PDT Monitoring - A fix has been implemented and we are monitoring the results. Apr 7, 00:15 PDT Identified - The issue has been identified and a fix is being implemented.

4. resolved Apr 07, 2026, 04:35 PM UTC

   This incident has been resolved.

5. postmortem Apr 08, 2026, 01:41 PM UTC

   **Summary:** Clients experienced “Something Went Wrong” errors throughout certain parts of the application. **Root Cause:** As part of ongoing security infrastructure improvements, FloQast migrated services to a more robust web application firewall \(WAF\) configuration. In pre-production environments, a supplemental ruleset had been in place that, by design, took precedence over certain standard security rules — effectively masking how those rules would behave in production. When the migration to the stricter production security configuration occurred, legitimate integration traffic was inadvertently caught and blocked. **Immediate Resolution:** Engineering teams performed a full rollback of the affected deployments, restoring integration functionality for impacted customers. Once stable, the team began a careful analysis of the specific security rules to confirm that the appropriate level of restrictions was being adhered to. **Follow-up Actions:** The team is taking a deliberate approach to reintroducing the production security ruleset in monitoring mode before enforcing blocks, allowing for validation against known traffic patterns.

Read the full incident report →

Started Apr 02, 2026, 01:54 PM UTC· resolved Apr 02, 2026, 05:46 PM UTC

1. investigating Apr 02, 2026, 01:54 PM UTC

   We are receiving reports of 403s when interacting with specific API endpoints such as our Trial Balance or Chart of Accounts endpoints

2. monitoring Apr 02, 2026, 03:47 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Apr 02, 2026, 05:46 PM UTC

   Apr 2, 10:46 PDT Resolved - The fix for this has been deployed, and the incident has been resolved. Apr 2, 08:47 PDT Monitoring - A fix has been implemented and we are monitoring the results. Apr 2, 06:54 PDT Investigating - We are receiving reports of 403s when interacting with specific API endpoints such as our Trial Balance or Chart of Accounts endpoints

4. resolved Apr 02, 2026, 05:46 PM UTC

   The fix for this has been deployed, and the incident has been resolved.

5. postmortem Apr 06, 2026, 06:16 PM UTC

   **Summary:** Clients experienced authorization errors \(403s\) when attempting to push data through FloQast's external API integration pipeline. **Root Cause:** As part of ongoing security infrastructure improvements, FloQast migrated services to a more robust web application firewall \(WAF\) configuration. In pre-production environments, a supplemental ruleset had been in place that, by design, took precedence over certain standard security rules — effectively masking how those rules would behave in production. When the migration to the stricter production security configuration occurred, legitimate integration traffic was inadvertently caught and blocked. **Immediate Resolution:** Engineering teams performed a full rollback of the affected deployments, restoring integration functionality for impacted customers. Once stable, the team began a careful analysis of the specific security rules to confirm that the appropriate level of restrictions was being adhered to. **Follow-up Actions:** The team is taking a deliberate approach to reintroducing the production security ruleset in monitoring mode before enforcing blocks, allowing for validation against known traffic patterns.

Read the full incident report →

Started Mar 31, 2026, 11:40 PM UTC· resolved Apr 01, 2026, 12:02 AM UTC

1. investigating Mar 31, 2026, 11:40 PM UTC

   We are currently aware of an issue resulting in specific admin settings pages not loading.

2. identified Mar 31, 2026, 11:51 PM UTC

   The issue has been identified and a fix is being implemented.

3. resolved Apr 01, 2026, 12:02 AM UTC

   Mar 31, 17:02 PDT Resolved - The fix has been deployed to all regions, and functionality is now restored. We will continue monitoring for any unexpected behavior. Mar 31, 16:51 PDT Identified - The issue has been identified and a fix is being implemented. Mar 31, 16:40 PDT Investigating - We are currently aware of an issue resulting in specific admin settings pages not loading.

4. resolved Apr 01, 2026, 12:02 AM UTC

   The fix has been deployed to all regions, and functionality is now restored. We will continue monitoring for any unexpected behavior.

5. postmortem Apr 01, 2026, 09:16 PM UTC

   **Summary:** Clients experienced failures when attempting to load most Admin pages within the application. The Team page remained accessible, but all other Admin pages were unavailable during the incident window, which lasted approximately 27 minutes. **Root Cause:** During a scheduled release, certain application components were deployed out of the intended order. Specifically, updated client code was deployed before the underlying services it depended on were in place, causing Admin pages to fail to load when users attempted to access them. **Immediate Resolution:** Engineering teams identified the deployment sequencing gap and completed the deployment of the missing components. Once the remaining services were deployed in the correct order, Admin page functionality was fully restored across all affected users. **Follow-up Actions:** To prevent similar occurrences, the team is implementing clearer documentation of deployment ordering requirements for complex releases, ensuring all dependencies are explicitly captured and confirmed with relevant stakeholders before deployments begin. Internal release coordination processes are also being reviewed to reduce the risk of sequencing gaps, particularly in releases involving multiple simultaneous updates.

Read the full incident report →

Started Feb 23, 2026, 09:00 PM UTC· resolved Feb 24, 2026, 12:00 AM UTC

1. resolved Feb 24, 2026, 12:00 AM UTC

   Feb 23, 16:00 PST Resolved - Resolution: Reverting the recent deployment fixed the issue. Feb 23, 13:00 PST Investigating - Summary: Recent deployment of a core service caused a cascading 500 error when users attempted to access TB (Trial Balance) upload folders. The error originated from a failed HTTP request with status code 500.

2. investigating Mar 02, 2026, 04:58 AM UTC

   Summary: Recent deployment of a core service caused a cascading 500 error when users attempted to access TB (Trial Balance) upload folders. The error originated from a failed HTTP request with status code 500.

3. resolved Mar 02, 2026, 05:00 AM UTC

   Resolution: Reverting the recent deployment fixed the issue.

Read the full incident report →

Started Feb 23, 2026, 03:06 PM UTC· resolved Feb 23, 2026, 03:42 PM UTC

1. investigating Feb 23, 2026, 03:06 PM UTC

   We are currently looking into an issue where a 500 error displays when using the AI creation method to generate a rule within the Matching product.

2. resolved Feb 23, 2026, 03:42 PM UTC

   Feb 23, 07:42 PST Resolved - This issue has been resolved after a newly introduced configuration requirement was made between FloQast and OpenAI. New regional configurations are now in place, and our team has validated that matching rules can be created in all three FloQast regional databases again (US, EU, AU). Feb 23, 07:06 PST Investigating - We are currently looking into an issue where a 500 error displays when using the AI creation method to generate a rule within the Matching product.

3. resolved Feb 23, 2026, 04:09 PM UTC

   This issue has been resolved after a newly introduced configuration requirement was made between FloQast and OpenAI. New regional configurations are now in place, and our team has validated that matching rules can be created in all three FloQast regional databases again (US, EU, AU).

Read the full incident report →

Started Feb 20, 2026, 03:54 PM UTC· resolved Feb 20, 2026, 08:30 PM UTC

1. investigating Feb 20, 2026, 03:54 PM UTC

   We have identified an issue where Checklist items are erroneously assigned a new Template ID when imported via the Single-Entity or All-Entities template. When an impacted template is applied via the Admin Settings > Checklist page, the updated Template ID causes a brand-new version of the checklist item to be created in the relevant periods. For items that have been fully signed off in those periods, absolutely no sign-off data is lost on the original item, but it will appear that the item has "duplicated" since this net-new version has also been added.

2. identified Feb 20, 2026, 07:04 PM UTC

   The issue has been identified and a fix is being implemented.

3. monitoring Feb 20, 2026, 07:30 PM UTC

   A fix for this issue has been implemented, preventing additional erroneous duplicate tasks from being created. Work is ongoing to correct the tasks that have already been created.

4. resolved Feb 20, 2026, 08:30 PM UTC

   Feb 20, 12:30 PST Resolved - This incident has been resolved. Feb 20, 11:30 PST Monitoring - A fix for this issue has been implemented, preventing additional erroneous duplicate tasks from being created. Work is ongoing to correct the tasks that have already been created. Feb 20, 11:04 PST Identified - The issue has been identified and a fix is being implemented. Feb 20, 07:54 PST Investigating - We have identified an issue where Checklist items are erroneously assigned a new Template ID when imported via the Single-Entity or All-Entities template. When an impacted template is applied via the Admin Settings > Checklist page, the updated Template ID causes a brand-new version of the checklist item to be created in the relevant periods. For items that have been fully signed off in those periods, absolutely no sign-off data is lost on the original item, but it will appear that the item has "duplicated" since this net-new version has also been added.

5. resolved Feb 23, 2026, 04:10 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 12, 2026, 01:57 PM UTC· resolved Feb 12, 2026, 03:20 PM UTC

1. investigating Feb 12, 2026, 01:57 PM UTC

   We are currently investigating an issue for our EMEA and APAC customers where an error message displays when clicking on a review note.

2. identified Feb 12, 2026, 02:51 PM UTC

   The issue has been identified and a fix is being implemented.

3. monitoring Feb 12, 2026, 02:54 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Feb 12, 2026, 03:20 PM UTC

   Feb 12, 07:20 PST Resolved - This incident has been resolved. Feb 12, 06:54 PST Monitoring - A fix has been implemented and we are monitoring the results. Feb 12, 06:51 PST Identified - The issue has been identified and a fix is being implemented. Feb 12, 05:57 PST Investigating - We are currently investigating an issue for our EMEA and APAC customers where an error message displays when clicking on a review note.

5. resolved Feb 12, 2026, 03:20 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 11, 2026, 09:38 PM UTC· resolved Feb 11, 2026, 10:07 PM UTC

1. identified Feb 11, 2026, 09:38 PM UTC

   We have received reports of intermittent 500 errors, specifically in the Journal Entry Management module. We have identified the issue and are actively working on releasing the fix.

2. resolved Feb 11, 2026, 10:07 PM UTC

   Feb 11, 14:07 PST Resolved - A fix has been implemented, and the issue is confirmed resolved. Feb 11, 13:38 PST Identified - We have received reports of intermittent 500 errors, specifically in the Journal Entry Management module. We have identified the issue and are actively working on releasing the fix.

3. resolved Feb 11, 2026, 10:07 PM UTC

   A fix has been implemented, and the issue is confirmed resolved.

Read the full incident report →

Started Feb 10, 2026, 08:35 PM UTC· resolved Feb 10, 2026, 09:12 PM UTC

1. investigating Feb 10, 2026, 08:58 PM UTC

   We are investigating reports of issues loading the Transform AI Agents page. We will provide an update as soon as more information is available.

2. identified Feb 10, 2026, 09:01 PM UTC

   The issue has been identified, and a fix is being implemented.

3. resolved Feb 10, 2026, 09:12 PM UTC

   Feb 10, 13:12 PST Resolved - This issue has been resolved, and the Transform AI Agents page is now fully operational. A Root Cause Analysis will be posted here when available. Feb 10, 13:01 PST Identified - The issue has been identified, and a fix is being implemented. Feb 10, 12:35 PST Investigating - We are investigating reports of issues loading the Transform AI Agents page. We will provide an update as soon as more information is available.

4. resolved Feb 10, 2026, 09:12 PM UTC

   This issue has been resolved, and the Transform AI Agents page is now fully operational. A Root Cause Analysis will be posted here when available.

5. postmortem Mar 30, 2026, 02:15 PM UTC

   **Summary:** Clients experienced failures when attempting to load the Transform module, receiving an error indicating that their user identity or team membership could not be validated. The issue affected all users attempting to access Transform during the incident window. **Root Cause:** A code update introduced a dependency on a new policy definition that had not yet been deployed to the supporting authentication service. When users attempted to load Transform, the system was unable to complete the required identity and access validation, resulting in a load failure. **Immediate Resolution:** Engineering teams quickly identified that the issue stemmed from a mismatch between the recently deployed code and the underlying authentication service. The update was reverted to the previous stable release, which did not rely on the unavailable policy. This restored normal Transform functionality for all users within approximately 22 minutes of the issue being detected. **Follow-up Actions:** To prevent similar occurrences, the team is reinforcing the practice of ensuring all service dependencies are deployed and verified before releasing dependent code changes. Additionally, efforts are underway to improve how the application handles upstream service unavailability, with the goal of providing clearer, more actionable messaging to users rather than a hard failure, and to better equip support teams for faster diagnosis.

Read the full incident report →

Started Jan 29, 2026, 03:00 PM UTC· resolved Jan 29, 2026, 09:03 PM UTC

1. investigating Jan 29, 2026, 04:54 PM UTC

   We are currently investigating reports of issues accessing AutoRec and AI Matching via the Folders tab. These modules remain functional and can be accessed from the Reconciliations tab as a workaround. Our engineering team is actively working to identify the root cause, and we will provide an update as soon as possible.

2. identified Jan 29, 2026, 06:49 PM UTC

   The issue has been identified, and a fix is being implemented.

3. resolved Jan 29, 2026, 09:03 PM UTC

   Jan 29, 13:03 PST Resolved - We have released a fix for this issue, and AutoRec and AI Matching can now be accessed from the Folders tab successfully. We are continuing to monitor for any further issues, and a Root Cause Analysis will be posted here when available. Jan 29, 10:49 PST Identified - The issue has been identified, and a fix is being implemented. Jan 29, 07:00 PST Investigating - We are currently investigating reports of issues accessing AutoRec and AI Matching via the Folders tab. These modules remain functional and can be accessed from the Reconciliations tab as a workaround. Our engineering team is actively working to identify the root cause, and we will provide an update as soon as possible.

4. resolved Jan 29, 2026, 09:03 PM UTC

   We have released a fix for this issue, and AutoRec and AI Matching can now be accessed from the Folders tab successfully. We are continuing to monitor for any further issues, and a Root Cause Analysis will be posted here when available.

5. postmortem Feb 02, 2026, 11:48 PM UTC

   **Summary:** Clients experienced navigation failures and error messages when attempting to access AI Matching, AutoRec Matching, AutoRec Amortization, and AutoRec Depreciation through the Folders page. Impacted users were able to load these modules from the Reconciliations tab. **Root Cause:** An update inadvertently changed how certain components were initialized. When users accessed these modules from the Folders page, a necessary navigation component was not properly loaded, leading to system errors during attempts to open the modules. **Immediate Resolution**: Engineering teams identified the problematic update and reverted the changes to a previous stable state. This restoration of the original loading sequence immediately resolved the navigation failures across all environments. **Follow-up Actions:** To prevent similar occurrences, the team is implementing enhanced automated regression testing specifically for secondary navigation paths and cross-module interactions. Additionally, internal review processes for shared application components are being updated to ensure architectural changes do not impact dependent modules.

Read the full incident report →

Started Jan 16, 2026, 05:10 PM UTC· resolved Jan 16, 2026, 11:33 PM UTC

1. investigating Jan 16, 2026, 05:10 PM UTC

   We are currently investigating an issue with the Quickbooks Online integration failing to refresh successfully.

2. investigating Jan 16, 2026, 09:57 PM UTC

   We are continuing to investigate this issue.

3. identified Jan 16, 2026, 11:12 PM UTC

   The issue has been identified and a fix is being implemented.

4. resolved Jan 16, 2026, 11:33 PM UTC

   Jan 16, 15:33 PST Resolved - The fix has been deployed, and we are seeing successes in each environment once again. We will continue to monitor and follow up on this post, including a root cause analysis, as soon as it is available. Jan 16, 15:12 PST Identified - The issue has been identified and a fix is being implemented. Jan 16, 13:57 PST Update - We are continuing to investigate this issue. Jan 16, 09:10 PST Investigating - We are currently investigating an issue with the Quickbooks Online integration failing to refresh successfully.

5. resolved Jan 16, 2026, 11:33 PM UTC

   The fix has been deployed, and we are seeing successes in each environment once again. We will continue to monitor and follow up on this post, including a root cause analysis, as soon as it is available.

6. postmortem Jan 21, 2026, 10:38 PM UTC

   **Summary:** Customers experienced an interruption in service where QuickBooks Online \(QBO\) entities failed to refresh, preventing accurate data synchronization and resulting in failure to retrieve balances. **Root Cause:** The third-party vendor, QuickBooks Online, implemented an unannounced update to their system's request validation rules. This change caused previously successful data requests from our application to be rejected by the vendor's infrastructure, despite the underlying integration logic remaining unchanged. **Immediate Resolution:** Our engineering team identified the specific change in the vendor’s validation requirements and deployed a hotfix to adjust the formatting of our data requests. This update ensures compliance with the vendor's new standards and has successfully restored full synchronization functionality across all production environments. **Follow-up Actions:** We are implementing enhanced, vendor-specific monitoring to detect external API anomalies more rapidly in the future. Additionally, we are auditing our existing alert thresholds to ensure our teams are notified immediately if integration success rates drop below expected levels, allowing for faster response times to third-party changes.

Read the full incident report →

Started Dec 19, 2025, 10:15 PM UTC· resolved Dec 19, 2025, 10:15 PM UTC

1. resolved Dec 19, 2025, 10:15 PM UTC

   Dec 19, 14:15 PST Resolved - Certain audit log events are not appearing within the audit log export during an impacted period.

2. resolved Mar 30, 2026, 09:15 PM UTC

   Certain audit log events are not appearing within the audit log export during an impacted period.

3. postmortem Mar 30, 2026, 09:16 PM UTC

   **Summary:** Certain audit log events were not visible within the platform during the impacted period. **Root Cause:** A code change intended to reduce duplicate backend log entries introduced a gap in event capture due to an unaddressed dependency in the release process. As a result, some audit log events were not properly recorded or displayed. **Immediate Resolution:**The code change was reverted to restore audit log functionality. Engineering identified the affected time window, recovered available audit log data, and restored visibility of impacted events. **Follow-up Actions:** The team reviewed and reinforced software development lifecycle \(SDLC\) processes, including validation of dependencies during testing and deployment. Additional controls have been implemented to ensure completeness and reliability of audit log capture going forward.

Read the full incident report →