GoFormz Status Page

Apr 16, 2026 · resolved Apr 16

This incident has been resolved. Please read on for a full post mortem of the incident. GoFormz Service Disruption on April 16, 2026 On April 16, 2026, GoFormz experienced a service disruption that made our application slow or unreachable for many users over a roughly 35-minute window. We know reliability is critical to your business, and we apologize for the disruption. Root Cause On April 15, 2026, GoFormz rolled out a maintenance process designed to clean up expired transient data in our database and keep the system running efficiently. After approximately 24 hours, this process began conflicting with normal application activity under real-world usage, causing database deadlocks. These deadlocks blocked access to our core database, leading to significant application latency and user-facing timeouts. The issue was mitigated by disabling the cleanup service and increasing database capacity. Impact to Customers: Application latency and user-facing timeouts. - Start of impact: 8:23 AM PDT - Mitigation began: 8:55 AM PDT - Service restored: 8:59 AM PDT During this window, you may have experienced very slow response times, login attempts that timed out in your browser, or been unable to access the application altogether. Why We Didn't Catch It Sooner GoFormz runs automated tests around the clock that simulate user logins to confirm the application is working. These tests only validated success, not performance. What We're Doing About It 1. We will be redesigning this database maintenance process so it cannot interfere with normal application activity, regardless of load. 2. Better monitoring. We're adjusting speed thresholds to our automated tests and adding a new layer of alerts so we're alerted the moment the application becomes too slow under such circumstances. This will address the gap in login performance testing. Again, we apologize for the disruption. If you have any questions, please reach out to our support team.

Dec 16, 2025 · resolved Dec 17

This incident has been resolved.

Oct 29, 2025 · resolved Oct 30

[https://azure.status.microsoft/en-us/status/history/](https://azure.status.microsoft/en-us/status/history/) The following information was shared by Microsoft Azure following this incident. > _This is our Preliminary PIR to share what we know so far. After our internal retrospective is completed \(generally within 14 days\) we will publish a Final PIR with additional details._ > > **What happened?** > > Between 15:45 UTC on 29 October and 00:05 UTC on 30 October 2025, customers and Microsoft services leveraging Azure Front Door \(AFD\) may have experienced latencies, timeouts, and errors. > > Affected Azure services include, but are not limited to: App Service, Azure Active Directory B2C, Azure Communication Services, Azure Databricks, Azure Healthcare APIs, Azure Maps, Azure Portal, Azure SQL Database, Azure Virtual Desktop, Container Registry, Media Services, Microsoft Copilot for Security, Microsoft Defender External Attack Surface Management, Microsoft Entra ID \(Mobility Management Policy Service, Identity & Access Management, and User Management UX\), Microsoft Purview, Microsoft Sentinel \(Threat Intelligence\), and Video Indexer. > > Customer configuration changes to AFD remain temporarily blocked. We will notify customers once this block has been lifted. While error rates and latency are back to pre-incident levels, a small number of customers may still be seeing issues and we are still working to mitigate this long tail. Updates will be provided directly via Azure Service Health. > > **What went wrong and why?** > > An inadvertent tenant configuration change within Azure Front Door \(AFD\) triggered a widespread service disruption affecting both Microsoft services and customer applications dependent on AFD for global content delivery. The change introduced an invalid or inconsistent configuration state that caused a significant number of AFD nodes to fail to load properly, leading to increased latencies, timeouts, and connection errors for downstream services. > > As unhealthy nodes dropped out of the global pool, traffic distribution across healthy nodes became imbalanced, amplifying the impact and causing intermittent availability even for regions that were partially healthy. We immediately blocked all further configuration changes to prevent additional propagation of the faulty state and began deploying a ‘last known good’ configuration across the global fleet. Recovery required reloading configurations across a large number of nodes and rebalancing traffic gradually to avoid overload conditions as nodes returned to service. This deliberate, phased recovery was necessary to stabilize the system while restoring scale and ensuring no recurrence of the issue. > > The trigger was traced to a faulty tenant configuration deployment process. Our protection mechanisms, to validate and block any erroneous deployments, failed due to a software defect which allowed the deployment to bypass safety validations. Safeguards have since been reviewed and additional validation and rollback controls have been immediately implemented to prevent similar issues in the future. > > **How did we respond?** > > 15:45 UTC on 29 October 2025 – Customer impact began. > > 16:04 UTC on 29 October 2025 – Investigation commenced following monitoring alerts being triggered. > > 16:15 UTC on 29 October 2025 – We began the investigation and started to examine configuration changes within AFD. > > 16:18 UTC on 29 October 2025 – Initial communication posted to our public status page. > > 16:20 UTC on 29 October 2025 – Targeted communications to impacted customers sent to Azure Service Health. > > 17:26 UTC on 29 October 2025 – Azure portal failed away from Azure Front Door. > > 17:30 UTC on 29 October 2025 – We blocked all new customer configuration changes to prevent further impact. > > 17:40 UTC on 29 October 2025 – We initiated the deployment of our ‘last known good’ configuration. > > 18:30 UTC on 29 October 2025 – We started to push the fixed configuration globally. > > 18:45 UTC on 29 October 2025 – Manual recovery of nodes commenced while gradual routing of traffic to healthy nodes began after the fixed configuration was pushed globally. > > 23:15 UTC on 29 October 2025 - PowerApps mitigation of dependency, and customers confirm mitigation. > > 00:05 UTC on 30 October 2025 – AFD impact confirmed mitigated for customers. > > **What happens next?** > > Our team will be completing an internal retrospective to understand the incident in more detail and will share findings within 14 days. Once we complete our internal retrospective, generally within 14 days, we will publish a final Post Incident Review \(PIR\) to all impacted customers.

Sep 16, 2025 · resolved Sep 17

### Postmortem: Email Delivery Interruption **Incident Duration:** * **Start:** Tuesday, September 16, 2025 at approximately 7:50 AM PT * **End:** Tuesday, September 16, 2025 at approximately 5:00 PM PT **Impact:** During this incident, **Email Delivery via Workflow, Template events, and Account Management \(reset password/invite user emails\)** were unavailable for all GoFormz accounts. **Root Cause:** Our email provider temporarily suspended outbound traffic from GoFormz due to suspicious activity. * **Important:** At no point was customer data exposed or put at risk. The suspicious activity was isolated to those specific accounts. **Resolution:** GoFormz worked closely with our provider to validate the issue, secure our systems, and restore normal service. **How this impacts you:** Most emails triggered to be sent during this time period _**were ultimately delivered after resolution.**_ However, some were not delivered. For those impacted emails, please follow the below remediation instructions: * **Template Events:** Re-trigger manually \(e.g., by opening/completing the form again\). * **Workflow Jobs:** Select the “...” actions button to the right of the job and click **“Rerun.”** * Customers can rerun these jobs one by one. * If you have a significant number of jobs to rerun, please reach out to our support team at [**[email protected]**](mailto:[email protected]) and we can help you bulk rerun batches. * **Password Reset Emails:** Resend password reset requests. Customers can resend in bulk from the **Users & Groups** page. **Preventive Measures:** We have strengthened safeguards with our email provider and are improving monitoring to reduce the likelihood of similar interruptions in the future.

Aug 25, 2025 · resolved Aug 26

**Postmortem: Mobile checkbox display issue \(August 21–25, 2025\)** **Resolved:** August 25, 2025 at 12:22 PM PT **Impact window:** August 21–25, 2025 **Affected platforms:** Android, iOS and Windows mobile apps \(version 4.0.1391\) **Issue summary:** Between August 21 and August 25, a bug in GoFormz mobile app version 4.0.1391 caused checkbox and checkbox group values to sometimes display incorrectly. The issue was limited to mobile forms using these field types and did not affect all forms and completions. **Root cause:** A recent mobile release introduced a logic error that affected how checkbox states were saved during certain form interactions. This led to a mismatch between user input and the final stored values. **Resolution:** The issue was resolved with mobile app version 4.0.1395, released to all app stores on August 25. Users must update to this version to prevent further occurrences. **Next steps for customers:** We recommend reviewing forms submitted between August 21 and August 25 using the mobile app version 4.0.1391, especially if they include checkbox fields. Not all forms in this timeframe are confirmed to be impacted, but reviewing them will help ensure data accuracy. **Preventive actions:** We are implementing additional automated testing for field-specific behavior in mobile forms and improving release QA processes for core field logic. We appreciate the customers who flagged this issue quickly and thank you for your patience while we worked toward a resolution.