Templafy Outage History

**Investigation** On April 1, 2026, a subset of customers began reporting issues when attempting to open or generate documents through app connectors. As a result, an incident was created at 10:58 AM CET. The engineering team investigated and identified two main issues. Some links from external systems were not directing users to the correct documents, and users encountered errors when accessing certain templates in filtered folders. Further analysis showed that recent changes introduced as part of the new user experience caused inconsistencies in how required data was passed between systems. This resulted in missing information needed to correctly locate and load documents. **Mitigation** Following identification of the issues, the engineering team prioritized restoring functionality. Work began shortly after detection by correcting external link routing and ensuring required data was available before documents were loaded. Temporary mitigation steps were applied to stabilize access while a full fix was prepared. Additional connector flows were also reviewed, including known variations such as the Stuf app connector. **Resolution** The issue was resolved at 5:40 PM CET on April 1, 2026, when fixes were deployed to restore document generation through app connectors. The implemented changes ensured that all required information was consistently available during the document creation process. After deployment, users were able to successfully generate documents and access templates without errors. The solution was validated across affected environments. **Post-Incident Actions** * Feature flag implementations will include options to exclude specific tenants during rollout * Test coverage will be expanded for app connectors, document access, and integration scenarios **Impact and Scope** This incident affected a subset of customers using app connectors within the new end-user experience. Impacted users experienced failures when opening or generating documents, particularly when accessing templates through filtered folders or external links. We sincerely apologize for the disruption caused by this incident. Maintaining a reliable and seamless experience is our highest priority, and we are taking steps to improve our release processes and testing coverage moving forward.

**Investigation** On March 31, 2026, at 12:02 PM CET, an issue began affecting access to Templafy for some customers hosted in West Europe \(Production 0\). The issue was detected at 12:09 PM CET through system alerts. The engineering team quickly began investigating and identified that part of the underlying Azure infrastructure supporting the service was not responding as expected. This resulted in temporary access issues for some users. **Mitigation** At 12:41 PM CET, the engineering team took steps to isolate the affected portion of the Azure infrastructure to prevent further impact. Traffic was redirected away from the affected area, allowing the platform to continue operating using healthy resources. From a user perspective, service was effectively restored at this point, and customers were able to access Templafy as expected. The team continued to closely monitor the system to ensure stability. **Resolution** The affected infrastructure was safely removed from service, and all systems were confirmed to be operating normally. This step reflects full backend recovery and validation, with no additional user impact observed after mitigation. **Post-Incident Actions** We are continuing to review this incident in collaboration with Microsoft Azure to better understand the underlying cause of the infrastructure disruption and to reduce the likelihood of recurrence. **Impact and Scope** This incident affected a subset of customers hosted in West Europe \(Production 0\), who experienced temporary difficulty accessing Templafy between 12:02 PM CET and 12:41 PM CET on March 31, 2026. The root cause was identified as an issue within Azure-managed infrastructure.

# Investigation The incident began on March 12, 2026, at 10:17 AM CET, when some users attempting to access [templafy.templafy.com](http://templafy.templafy.com) from mobile devices experienced difficulties loading the site. The issue was detected at 1:36 PM CET, after reports indicated that the site could not be accessed successfully from certain mobile clients. The engineering team began investigating immediately after detection. The issue was related to an ongoing infrastructure change where traffic was gradually being moved from the current routing component to a new one. During this transition, a configuration difference in the new system caused some requests to be rejected. This issue mainly affected users accessing the service from mobile devices. # Mitigation Once the cause was identified, the engineering team mitigated the issue by redirecting traffic back to the previous routing component. This rollback restored the previous routing behavior and prevented further request validation conflicts, allowing the team to continue analyzing the routing component configuration. # Resolution The incident was resolved on March 12, 2026, at 2:31 PM CET, once traffic had been fully reverted to the previous infrastructure configuration. Following the rollback, affected users were again able to access [templafy.templafy.com](http://templafy.templafy.com) from mobile devices without issues. # Impact and Scope This incident affected users attempting to access [templafy.templafy.com](http://templafy.templafy.com) from mobile devices during the migration window on March 12, 2026. The issue occurred during a controlled infrastructure migration and impacted requests routed through the following clusters: * West Europe \(Production 0\) * Australia East \(Production 3\) * West Europe \(Production 5\) Users accessing the service from mobile devices connected to these clusters may have experienced difficulty loading the site during the incident window. # Post-Incident Actions Following the incident, the engineering team reviewed the migration process and identified improvements to the procedures used during infrastructure transitions. These improvements will help ensure smoother migrations and reduce the likelihood of similar issues occurring in the future.

## Investigation The incident began on March 10, 2026, at 8:04 AM CET and affected document generation and download functionality for some users. In certain cases, documents could fail to generate when templates contained non-ASCII characters in the file name. Additionally, some downloaded documents appeared corrupted. The issue was detected on March 10, 2026, at 1:58 PM CET, after alerts indicated unusual behavior related to document processing. The engineering team immediately began investigating the issue. During the investigation, the team found that a recent change related to how documents were stored in blob storage within the Dynamics integration had introduced unexpected behavior. This change caused templates with certain characters in their names to fail during document creation and also led to incorrect references to stored documents, which resulted in corrupted downloads. ## Mitigation The engineering team reverted the recent blob storage changes introduced in the Dynamics integration and removed metadata related to template names that contributed to the failures. The team also corrected the document identification and storage logic to ensure documents were saved and retrieved correctly. These steps restored normal behavior for document generation and downloads. ## Resolution The fix was deployed on March 10, 2026, and was successfully rolled out to **West Europe \(Production 0\)** by 3:56 PM CET. Following the deployment, document creation and downloads returned to normal operation. ## Impact and Scope This incident affected document creation and document download functionality for customers hosted on **West Europe \(Production 0\)**. During the incident window from March 10, 2026, at 8:04 AM CET until March 10, 2026, at 3:56 PM CET, users could experience issues generating documents from templates with certain characters in their names or receive corrupted files when downloading documents. ## Post-Incident Actions The engineering team reviewed the incident and identified opportunities to further improve validation around document storage. As part of the follow-up actions: * Automated tests will be expanded to validate storage paths before documents are stored. * Additional validation will ensure that document identifiers and storage locations remain consistent during processing. * The team will continue improving how template name metadata is handled to support a wider range of naming conventions.

# Investigation The incident began on March 5, 2026, at 8:04 AM CET and affected the Document Updater functionality for PowerPoint presentations, where users encountered an error when attempting to update presentations. As a result, PowerPoint presentations could not be updated through the Document Updater. The issue was detected on March 9, 2026, at 9:32 AM CET, after reports indicated that users were receiving error notifications when attempting to update PowerPoint documents. The engineering team immediately initiated an investigation to determine the cause of the issue. During the investigation, the team identified that a recently introduced change related to the Templafy Validator functionality for unlocking slides had unintentionally introduced a regression affecting the Document Updater. The change modified the contract used by the VSTO component responsible for processing template configuration. Due to this contract change, VSTO was unable to correctly process the configuration, resulting in errors when users attempted to update PowerPoint presentations. # Mitigation After identifying the cause of the issue on March 9, 2026, at 9:41 AM CET, the engineering team began implementing a fix to restore compatibility with the existing VSTO integration. A corrective code change was prepared. The fix ensured that the contract used by the VSTO component could once again correctly process template configuration required by the Document Updater. # Resolution By 12:05 PM CET on March 9, 2026, the fix had been successfully deployed across all production clusters. Once deployed, the Document Updater functionality for PowerPoint presentations was restored, and users were able to update presentations normally without encountering errors. # Impact and Scope This incident affected the PowerPoint Document Updater functionality, preventing users from updating PowerPoint presentations through the platform. The issue impacted tenants across all production clusters, affecting all tenants using the PowerPoint update functionality during the incident window from March 5, 2026, at 8:04 AM CET until March 9, 2026, at 12:05 PM CET. # Post-Incident Actions The engineering team has reviewed the incident and identified opportunities to improve safeguards around compatibility between platform components. As part of the follow-up actions: • Additional review procedures will be introduced for changes that affect contracts used by client integrations such as VSTO. • The team will investigate approaches for introducing tests that validate backwards compatibility for contract changes, particularly for integrations that rely on existing client-side implementations. • Internal development guidelines will be reinforced to ensure that contract changes are carefully evaluated for potential downstream impact. These improvements aim to reduce the risk of similar regressions in the future.

# Investigation The incident began on March 4, 2026, at 8:04 AM CET, when Templafy assets were not visible in the new end-user experience within the Hive environment. The issue affected users attempting to access templates through the updated experience. The issue was detected at 9:07 AM CET after reports indicated that templates were missing from the library interface in the new experience. The engineering team immediately initiated an investigation to determine the cause of the behavior. During the investigation, the team reviewed recent changes related to Library and the handling of space-aware data. The analysis identified that recent hardening improvements intended to strengthen security around space-aware data had unintentionally introduced filtering conditions that prevented assets from appearing in the new end-user experience, even when users had the correct permissions. # Mitigation At approximately 9:27 AM CET on March 4, 2026, the engineering team began implementing mitigation steps after identifying the likely source of the issue. The team determined that reverting the recent changes related to the filtering logic would restore the expected behavior. Work to revert the changes was initiated shortly after confirmation of the root cause, and updates were communicated internally throughout the mitigation process. # Resolution At 10:15 AM CET on March 4, 2026, the rollback of the filtering changes was completed on West Europe \(Production 0\). Following the rollback, the library filtering behavior returned to normal, and Templafy assets became visible again in the new end-user experience for affected users. Verification confirmed that users with the appropriate permissions could once again access templates as expected. # Impact and Scope The incident affected tenants hosted on West Europe \(Production 0\) where the new end-user experience feature flag or document agents with library functionality enabled were in use. During the incident window, affected users were unable to see Templafy assets within the new end-user experience in Hive. The issue did not impact the underlying assets themselves, and access was restored once the filtering logic was reverted. # Post-Incident Actions The engineering team has identified several follow-up actions to further strengthen reliability and prevent similar issues in the future: • Establish a clearly maintained list of feature flags that are in public preview or that should be treated as production-impacting if affected by regressions. • Improve internal testing capabilities to support manual testing scenarios with the new end-user experience, including multiple feature flag configurations. • Introduce smoke tests for the Library Explorer in the new end-user experience to ensure asset visibility and filtering behavior remain consistent across releases. These improvements will help ensure that feature interactions and configuration scenarios are validated more thoroughly prior to deployment.

# Investigation On February 23, 2026, at 11:00 AM CET, an issue was introduced affecting specific pages within the Library Insights section of the platform. The issue impacted administrators attempting to access certain pages within Library Content Insights, where the pages would crash and prevent data from being displayed. Other areas of the platform remained fully operational. The issue was detected on February 24, 2026, at 9:00 AM CET, after reports indicated that affected pages were not loading as expected. The engineering team started the investigation immediately. Through log analysis and reproduction in a controlled environment, the team identified that a recent software update had introduced a conflict within the rendering flow of the affected pages. More specifically, a recent update to the third-party dependency triggered an unintended infinite rendering loop when handling links embedded in a data table within Library Content Insights. This resulted in page crashes for administrators accessing those specific views. No data loss occurred, as the issue was isolated to the presentation layer. # Mitigation At 10:27 AM CET on February 24, 2026, the engineering team initiated a rollback of the recent update as a mitigation measure. The rollback was first validated in a staging environment to confirm that the rendering issue was resolved and that no additional side effects were introduced. Once validated, the rollback was prepared for deployment across production clusters. # Resolution At 12:04 PM CET on February 24, 2026, the rollback to the previous stable version was successfully deployed across all production clusters. Following deployment, administrators were able to access all pages within Library Insights without further crashes. The rendering loop was eliminated, and normal functionality was fully restored. # Impact and Scope The incident affected administrators with access to Library Content Insights across all production clusters. The issue was limited to specific pages within the Library Insights section and did not impact other platform functionality. No data was lost, altered, or compromised. The incident was strictly related to page rendering and presentation. # Post-Incident Actions To reduce the likelihood of similar issues in the future, we are implementing the following actions: • Introducing an end-to-end test specifically covering Library Content Insights to ensure critical user journeys are validated before deployment. • Expanding automated regression coverage for third-party dependency updates. • Enhancing release validation procedures for frontend dependency upgrades to better detect rendering-related regressions. These improvements will strengthen our ability to detect presentation-layer issues before they reach production.

**Investigation** The issue began on February 20, 2026, at 11:42 AM CET in the Hive environment on West Europe \(Production 0\), where public API requests started failing due to an authentication problem. The incident was detected by the engineering team at 1:09 PM CET, and the team promptly began investigating. The cause was quickly identified as being related to recent changes in how user logins are handled. **Mitigation** To restore service as quickly as possible, the engineering team rolled back the recent changes to the authentication system. This rollback was implemented promptly after the root cause was identified, and system functionality was closely monitored to ensure public API access was restored. **Resolution** Normal API functionality was restored shortly after the rollback. The incident was considered resolved once user authentication to the public API was verified as successful across the environment. **Post-Incident Actions** After resolution, the engineering team began a thorough review of the deployment process and the changes that contributed to the incident. The following actions are being taken: * Automated checks will be put in place to confirm that critical features, such as public API access, work as expected after any changes. * Our monitoring will be improved so that potential issues with user authentication are detected even sooner. **Impact and Scope** The incident was limited to tenants in the West Europe \(Production 0\) environment. During the incident window, affected users were unable to log in or make successful requests through the public API. Other environments and clusters were not impacted. ‌ We sincerely apologize for the disruption caused by this incident. Maintaining a reliable and seamless experience remains our highest priority, and we are taking immediate steps to further improve our service reliability.

**Investigation** On February 17, 2026, at 11:26 PM CET, we detected an issue where the Library Insights feature in the Hive environment began timing out. The issue affected administrators with space owner permissions who were accessing analytics data within Library Insights. The engineering team initiated the Investigation phase on February 18, 2026, at 12:12 PM CET. Early analysis identified that SQL queries against the database were experiencing elevated CPU usage, reaching sustained peaks that resulted in query timeouts. Further review showed that specific filter-related queries \(such as application, countries, and departments\) were contributing to the increased database load. The team focused on stabilizing database performance while continuing a deeper analysis of the query patterns contributing to the issue. **Mitigation** As an immediate mitigation step, the engineering team increased the compute capacity of the database. The initial capacity increase did not fully alleviate the performance constraints, and additional scaling actions were taken. By 1:26 PM CET on February 18, 2026, after the additional scaling adjustments were completed, database CPU utilization stabilized and query timeouts ceased. The team continued monitoring the system closely to ensure sustained stability. **Resolution** By 1:26 PM CET on February 18, 2026, the increased database capacity successfully stabilized the environment and restored consistent functionality to the Library Insights feature. No further disruptions were reported after the scaling adjustments were completed. Performance levels returned to expected operational thresholds following continued monitoring and system stabilization. Post-Incident Actions Following the incident, we initiated a deeper review of the query patterns used in Library Insights. As part of our follow-up actions: * We will revise how certain database queries are generated, particularly those involving complex filtering logic, to ensure more efficient execution plans. * We will reduce reliance on query constructs that may not scale efficiently with increased data volumes. * We will enhance performance testing scenarios to better simulate high-load conditions in analytics-related features. These improvements are intended to strengthen performance resilience as data volumes continue to grow. **Impact and Scope** The incident impacted the Library Insights feature within the Hive environment. Scope of impact: * Affected users were limited to administrators with space owner permissions. * The issue manifested as timeouts when accessing analytics data. * No other product areas were affected. The disruption was limited in scope and did not impact end users outside of the administrative analytics functionality. We sincerely apologize for the disruption caused by this issue. Ensuring reliable performance and a seamless experience for administrators and end users alike remains our highest priority. We are implementing the improvements outlined above to further strengthen system stability and prevent similar occurrences in the future.

# Investigation On February 9, 2026, at 8:19 AM CET, an issue began affecting the database. The incident was detected shortly after at 8:22 AM CET, when automated monitoring raised an alert indicating that database CPU utilization had reached 100%. As CPU utilization increased, the database reached its maximum connection limit, which caused dependent services to become slow or unresponsive for users in the affected environment. The engineering team initiated an investigation immediately after detection and analyzed database performance metrics and active workloads. By 9:05 AM CET, the team identified that the database stopped accepting new connections from services. The investigation revealed that a recently introduced query change was contributing to excessive CPU consumption under certain data conditions. # Mitigation and Resolution To stabilize the platform and restore service responsiveness, the engineering team implemented an immediate mitigation at 9:15 AM CET by scaling up the database server. This action increased available compute capacity and reset active database connections, allowing blocked operations to complete and preventing further connection exhaustion. The mitigation reduced CPU pressure and enabled services to gradually recover while further validation was performed. Shortly after, the database had fully stabilized, connection limits were no longer being reached, and all dependent services were operating normally. Continuous monitoring confirmed that CPU utilization had returned to expected levels and that user-facing functionality was fully restored. # Impact and Scope The incident affected most users served by West Europe \(Production 1\). During the incident window, users may have experienced slow responses or temporary unavailability in services relying on the database. No other production clusters were impacted. # Post-Incident Actions Following the incident, the engineering team defined several follow-up actions to reduce the risk of similar issues occurring in the future: • Expanding test datasets to better reflect production-scale data and diverse data distributions when validating performance-sensitive changes • Increasing internal awareness and knowledge sharing around database query optimization behavior and execution plan variability • Investigating broader technical solutions and tooling to help detect and mitigate database execution plan selection issues before deployment These actions are aimed at strengthening our validation processes and improving overall platform resilience.