Templafy Outage History

Started Sep 29, 2026, 05:01 PM UTC· resolved Sep 29, 2026, 06:58 PM UTC

1. investigating Sep 29, 2026, 05:01 PM UTC

   Intermittent request failures and increased latency across Azure OpenAI, Azure AI Foundry, and Cognitive Services. We are following the updates from Microsoft.

2. monitoring Sep 29, 2026, 06:56 PM UTC

   Microsoft pushed a fix which seems to resolve the issue. We will monitor document agents in Templafy at this point of time.

3. resolved Sep 29, 2026, 06:58 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Oct 01, 2026, 08:16 AM UTC

   # Investigation On September 29, 2026, at approximately 12:03 PM CET, an upstream Microsoft Azure platform issue began affecting services supporting Document Agents. Customers experienced Document Agents not responding as expected. Requests to the supporting Microsoft services experienced intermittent failures, increased latency, and HTTP 5XX errors. The investigation identified an upstream Microsoft Azure platform issue affecting Azure OpenAI Service, Foundry Agent Service, Foundry Models, and Cognitive Services. The disruption primarily affected services hosted in Sweden Central, with regional impact also observed in Spain Central. As the investigation progressed, the engineering team monitored updates from Microsoft and validated Document Agent functionality internally to determine when the dependent services had recovered. # Mitigation The engineering team continued monitoring the affected Azure services while Microsoft worked to restore the impacted platform components. At approximately 8:54 PM CET on September 29, 2026, Microsoft implemented remediation for the underlying platform issue. Following this change, our engineering team began monitoring service recovery and performed internal tests of Document Agents to confirm that requests were completing successfully. The team maintained an observation period to ensure that service health remained stable before closing the incident. # Resolution Following Microsoft's remediation, the affected Azure services recovered and Document Agent functionality returned to normal. The engineering team confirmed through monitoring and internal testing that Document Agents were responding successfully and that the previously observed request failures had subsided. The incident was resolved at 9:03 PM CET on September 29, 2026, after service stability had been confirmed. # Impact and Scope The incident affected Document Agents for customers served by the following production clusters: * West Europe \(Production 0\) * West Europe \(Production 1\) * West Europe \(Production 5\) Document Agents depend on Azure OpenAI Service to function. Affected customers could experience Document Agents not responding, intermittent request failures, or increased latency. The customer impact was caused by the Microsoft Azure platform disruption affecting the supporting services in Sweden Central. No data loss was identified as part of this incident. # Post-Incident Actions This incident was caused by an upstream Microsoft Azure platform issue. Document Agents depend on Microsoft services, and recovery during this incident depended on Microsoft's remediation. We are reviewing options to improve resilience against regional failures affecting these critical cloud dependencies. In particular, we will evaluate additional regional failover capabilities for the services supporting Document Agents so that workloads can be redirected when an underlying Azure region becomes unavailable or degraded. These measures may help reduce customer impact from future disruptions, while Document Agents remain dependent on the availability of the supporting Microsoft services.

Read the full incident report →

Started Sep 08, 2026, 08:24 AM UTC· resolved Sep 09, 2026, 08:09 AM UTC

1. identified Sep 08, 2026, 08:24 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Some customers might experience issues in using the find template and update document functionality in the Word VSTO Add-ins. Further updates will be posted here soon.

2. monitoring Sep 08, 2026, 11:49 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Sep 09, 2026, 08:09 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Sep 15, 2026, 02:15 PM UTC

   ## Investigation A small number of users across two tenants reported issues when using **Find Template** and **Update Document** in the VSTO add-in. The engineering team investigated the reported behavior and reviewed the available client-side diagnostic information. The issue could not be reproduced in our internal environments, and the investigation found no indication of a broader service degradation, back-end issue, or change affecting the VSTO add-in generally. The available diagnostics indicated that the affected clients encountered a failure while initializing a local web component used by the add-in. Find Template was the initial functionality affected, which could subsequently affect other functionality such as Update Document. Based on the investigation and the very limited number of affected users, we determined that this was **not a service-wide incident**, but an isolated client-side issue affecting specific user environments. ## Mitigation The engineering and support teams worked with the affected customers to collect diagnostic information and investigate potential environmental factors. Updating the VSTO add-in was also evaluated as part of the troubleshooting process. This did not consistently resolve the reported behavior, further indicating that the issue was not associated with a specific VSTO release. As the issue was isolated to a small number of users and could not be reproduced in our environments, troubleshooting focused on the affected local environments rather than making changes to the production service. ## Resolution The investigation did not identify a definitive root cause. However, the available evidence indicated that the behavior was specific to the affected client environments rather than a broader issue with the Templafy service. Potential contributing factors included the state of locally installed components, the local Microsoft Office environment, or recent environmental updates. None of these factors independently reproduced the behavior during our investigation. As no broader service impact was identified, the event was determined **not to constitute a production incident**. The reported behavior continues to be tracked through our standard product investigation and escalation processes. ## Impact and Scope The reported issue had a **very limited scope**, affecting only a small number of users across two tenants. There was no evidence of an impact to other tenants, a production cluster, the Templafy back-end services, or the broader VSTO user base. The investigation therefore concluded that the reports represented isolated client-side behavior rather than a wider service incident. We sincerely apologize for the disruption experienced by the affected users. Maintaining a reliable and seamless experience remains a high priority, and we will continue investigating these isolated reports and monitoring for any evidence of a broader pattern.

Read the full incident report →

Started Aug 14, 2026, 02:31 PM UTC· resolved Aug 14, 2026, 02:57 PM UTC

1. identified Aug 14, 2026, 02:31 PM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Users could encounter issues when updating Word documents using VSTO add-ins. Further updates will be posted here soon.

2. resolved Aug 14, 2026, 02:57 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

3. postmortem Aug 19, 2026, 11:59 AM UTC

   **Investigation** The incident began at 11:19 AM CET on August 12, 2026, following the promotion of Office VSTO add-ins version 7.3.220 to the stable release channel. The issue was detected at 10:25 PM CET on August 13, 2026, after customers reported that Microsoft Word could close unexpectedly when using the **Update Document with templates containing images.** The engineering team investigated the reported behavior and identified that a change introduced in version 7.3.220 affected the processing of newly inserted images within document headers during an update. Under certain document and Word view conditions, header content could not be processed reliably, causing the document update to fail or, in some cases, Word to close unexpectedly. **Mitigation** Following the investigation, the engineering team removed version 7.3.220 from the stable release channel to prevent further users from receiving the affected version. The team restored version 7.3.217 as the stable release, providing users with the previously validated version while the behavior introduced in 7.3.220 was addressed. **Resolution** The incident was resolved at 5:08 PM CET on August 14, 2026, by reverting the stable release to version 7.3.217. This removed the affected behavior from the stable release channel and restored the **Update Document** functionality to its expected operation. The engineering team verified the mitigation and confirmed that the product was functioning as expected following the rollback. **Post-Incident Actions** We are strengthening our release validation to reduce the likelihood of similar issues reaching the stable release channel. These improvements include additional manual validation when introducing new plugin versions and more robust dependency validation when updated plugin components are consumed by other Office components. We are also expanding automated coverage, with a particular focus on integration testing for document update scenarios and interactions with Microsoft Office applications. Impact and Scope The incident affected multiple tenants using version 7.3.220 of the Office VSTO add-ins. Users could encounter failures or unexpected Word application closures when using the **Update Document** functionality, temporarily obstructing affected document workflows. We sincerely apologize for the disruption caused by this incident. Maintaining a reliable and stable experience is a high priority for us, and we are strengthening our testing and release validation processes to help prevent similar issues in the future. We remain committed to delivering a dependable service to our customers.

Read the full incident report →

Started Jun 24, 2026, 12:54 PM UTC· resolved Jun 24, 2026, 02:42 PM UTC

1. identified Jun 24, 2026, 01:17 PM UTC

   Customers using West Europe (Production 0) may have experienced errors or delays while loading the application. Further updates will be posted here soon.

2. monitoring Jun 24, 2026, 01:23 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Jun 24, 2026, 02:42 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Jun 26, 2026, 12:16 PM UTC

   **Investigation** On **June 24, 2026**, 2:54 PM CET the engineering team identified an issue affecting the gateway infrastructure responsible for routing customer traffic. As a result, some requests were directed to service instances that were no longer available, causing intermittent request failures. The investigation determined that the gateway controller responsible for managing traffic routing did not consistently refresh its routing configuration following infrastructure changes, such as deployments or platform scaling events. This caused outdated routing information to remain active on some gateway instances, resulting in traffic being sent to endpoints that were no longer serving requests. The issue affected both **West Europe \(Production 0\)** and **West Europe \(Production 5\)** during separate deployment activities. **Mitigation** The engineering team immediately initiated mitigation by restarting the gateway instances responsible for traffic routing. Restarting these components forced the routing configuration to refresh, allowing traffic to be directed to the correct service instances. The mitigation successfully restored normal traffic routing for: * **West Europe \(Production 0\):** 2:54 PM CET – 3:08 PM CET * **West Europe \(Production 5\):** 3:22 PM CET – 3:42 PM CET Following the incident, the engineering team worked closely with the gateway vendor to investigate the observed behavior and evaluate long-term remediation options. **Resolution** The issue was resolved after the affected gateway instances were restarted and the routing configuration was successfully refreshed. As an additional precaution, the gateway component was subsequently downgraded to a previously proven stable version while the investigation with the vendor continues. **Post-Incident Actions** The engineering team completed a detailed review of the incident together with the gateway vendor to better understand the observed behavior. To reduce the likelihood of similar incidents, we have: * Reverted to a stable gateway controller version while the vendor continues its investigation. * Increased monitoring of gateway configuration synchronization during deployments and scaling events. * Continued collaboration with the vendor to validate future gateway releases before production rollout. **Impact and Scope** The incident affected a subset of customer requests hosted in the following production clusters: * **West Europe \(Production 0\):** June 24, 2026, from **2:54 PM CET** until **3:08 PM CET** * **West Europe \(Production 5\):** June 24, 2026, from **3:22 PM CET** until **3:42 PM CET** During these periods, some requests failed because traffic was temporarily routed to service instances that were no longer available. Once the gateway configuration was refreshed, normal service resumed. We sincerely apologize for the disruption caused by this incident. Providing a reliable and dependable service remains our highest priority, and we are continuing to work closely with our technology partners while strengthening our deployment and monitoring processes to help prevent similar issues in the future.

Read the full incident report →

Started Jun 08, 2026, 07:45 AM UTC· resolved Jun 08, 2026, 02:45 PM UTC

1. identified Jun 08, 2026, 12:40 PM UTC

   Microsoft reported that, starting at 09:36 UTC on 8 June 2026, it identified an incident affecting the Azure OpenAI Service in multiple regions. Further updates will be posted here soon.

2. monitoring Jun 08, 2026, 02:37 PM UTC

   At 13:45 UTC on 08 June 2026, Microsoft confirmed that the platform issue affecting Azure OpenAI Service across multiple regions had been mitigated.

3. resolved Jun 08, 2026, 02:45 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly.

4. postmortem Jun 10, 2026, 09:01 AM UTC

   # Investigation On June 8, 2026, at 10:01 AM CET, the engineering team became aware of delays and intermittent failures affecting AI-powered functionality within Document Agents, including outline preparation and document generation. The engineering team determined that the disruption originated from an incident affecting Microsoft Azure OpenAI Services across multiple regions. As Azure OpenAI is a dependency for AI Assistant functionality, increased latency and timeout rates in the external service impacted the processing of AI requests. While the platform continued to accept requests, slower response times caused a buildup of pending AI requests. As a result, some users experienced delays when generating outlines and documents, and in some cases workflows appeared stalled while requests were being processed. # Mitigation Following identification of the underlying cause, the engineering team focused on reducing delays and restoring normal processing capacity. The engineering team promptly implemented mitigation measures to reduce the impact of the Azure OpenAI service degradation and restore normal processing of AI requests. In parallel, Microsoft worked to restore normal Azure OpenAI service performance. These actions helped stabilize the service and reduce the impact on users while the external service disruption was being resolved. # Resolution The issue was resolved at 5:00 PM CET on June 8, 2026. Following Microsoft's remediation of the Azure OpenAI service disruption and the mitigation measures implemented by the engineering team, AI request processing returned to normal levels. After resolution, users were once again able to generate outlines and documents through Document Agents without abnormal delays or failures. The engineering team validated that service performance had returned to expected operating levels before closing the incident. # Post-Incident Actions To improve resilience and visibility into similar situations, the following actions have been identified: * Implement additional monitoring and alerting for AI service latency and timeout rates. * Add alerts for unusual increases in pending AI requests and processing delays. * Review scaling and recovery procedures to ensure faster response to external service disruptions. * Continue evaluating opportunities to improve the resilience of AI-powered functionality. # Impact and Scope This incident affected AI-powered functionality used by AI Assistant and Document Agents between 9:45 AM CET and 5:00 PM CET on June 8, 2026. A subset of users experienced delayed responses, failed AI requests, or workflows that appeared stuck while outlines or documents were being generated. The impact was caused by increased latency and timeout rates in Microsoft Azure OpenAI Services. We sincerely apologize for the disruption caused by this issue. Maintaining a reliable and seamless experience is our highest priority. We remain committed to delivering a dependable and high-quality service experience.

Read the full incident report →

Started Apr 01, 2026, 09:20 AM UTC· resolved Apr 02, 2026, 11:08 AM UTC

1. identified Apr 01, 2026, 09:20 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. identified Apr 01, 2026, 12:39 PM UTC

   The engineers have identified the root cause and are working towards a fix.

3. monitoring Apr 01, 2026, 03:35 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

4. resolved Apr 02, 2026, 11:08 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

5. postmortem Apr 08, 2026, 02:02 PM UTC

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

Read the full incident report →

Started Mar 31, 2026, 10:02 AM UTC· resolved Mar 31, 2026, 11:57 AM UTC

1. identified Mar 31, 2026, 11:01 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. monitoring Mar 31, 2026, 11:04 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Mar 31, 2026, 11:57 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Apr 03, 2026, 10:28 AM UTC

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

Read the full incident report →

Started Mar 12, 2026, 01:08 PM UTC· resolved Mar 12, 2026, 02:50 PM UTC

1. identified Mar 12, 2026, 01:08 PM UTC

   We have identified an issue that affects a subset of customers on West Europe (Production0), Australia East (Production 3), West Europe (Production5) and are working towards a resolution. Further updates will be posted here soon.

2. monitoring Mar 12, 2026, 01:20 PM UTC

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

3. resolved Mar 12, 2026, 02:50 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Mar 16, 2026, 02:28 PM UTC

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

Read the full incident report →

Started Mar 10, 2026, 01:28 PM UTC· resolved Mar 10, 2026, 02:47 PM UTC

1. identified Mar 10, 2026, 01:28 PM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. resolved Mar 10, 2026, 02:47 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

3. postmortem Mar 13, 2026, 08:26 AM UTC

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

Read the full incident report →

Started Mar 09, 2026, 08:54 AM UTC· resolved Mar 09, 2026, 11:12 AM UTC

1. investigating Mar 09, 2026, 08:54 AM UTC

   We are currently investigating this issue.

2. identified Mar 09, 2026, 09:43 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

3. resolved Mar 09, 2026, 11:12 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Mar 11, 2026, 08:33 AM UTC

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

Read the full incident report →

Started Mar 04, 2026, 08:35 AM UTC· resolved Mar 04, 2026, 09:13 AM UTC

1. investigating Mar 04, 2026, 08:35 AM UTC

   We are currently investigating this issue.

2. identified Mar 04, 2026, 08:51 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

3. resolved Mar 04, 2026, 09:13 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Mar 06, 2026, 08:36 AM UTC

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

Read the full incident report →

Started Feb 24, 2026, 08:53 AM UTC· resolved Feb 24, 2026, 11:06 AM UTC

1. investigating Feb 24, 2026, 08:53 AM UTC

   We are currently investigating this issue.

2. investigating Feb 24, 2026, 09:00 AM UTC

   We are continuing to investigate this issue.

3. identified Feb 24, 2026, 09:53 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

4. monitoring Feb 24, 2026, 10:53 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

5. resolved Feb 24, 2026, 11:06 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

6. postmortem Mar 02, 2026, 01:17 PM UTC

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

Read the full incident report →

Started Feb 20, 2026, 01:36 PM UTC· resolved Feb 20, 2026, 02:29 PM UTC

1. investigating Feb 20, 2026, 01:36 PM UTC

   We are currently investigating this issue.

2. identified Feb 20, 2026, 02:22 PM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

3. resolved Feb 20, 2026, 02:29 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Feb 23, 2026, 04:20 PM UTC

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

Read the full incident report →

Started Feb 18, 2026, 11:20 AM UTC· resolved Feb 18, 2026, 01:18 PM UTC

1. identified Feb 18, 2026, 11:20 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Admins in West Europe (Production 1) and East US (Production 2) may experience delays when accessing Library Insights. Further updates will be posted here soon.

2. monitoring Feb 18, 2026, 12:17 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Feb 18, 2026, 01:18 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Feb 20, 2026, 03:15 PM UTC

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

Read the full incident report →

Started Feb 09, 2026, 07:30 AM UTC· resolved Feb 09, 2026, 03:28 PM UTC

1. identified Feb 09, 2026, 09:11 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. monitoring Feb 09, 2026, 09:14 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Feb 09, 2026, 03:28 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Feb 10, 2026, 03:14 PM UTC

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

Read the full incident report →

Started Jan 29, 2026, 01:21 PM UTC· resolved Jan 29, 2026, 04:12 PM UTC

1. identified Jan 29, 2026, 01:21 PM UTC

   We have identified an issue that affects a subset of customers in West Europe (Production 0), West Europe (Production 1), West Europe (Production 5) and are working towards a resolution. We are impacted by an Open AI service availability in Azure, due to this some request using Document Agents and AI Assistant could experience degraded performance. Further updates will be posted here soon.

2. monitoring Jan 29, 2026, 04:07 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. monitoring Jan 29, 2026, 04:08 PM UTC

   We are continuing to monitor for any further issues.

4. resolved Jan 29, 2026, 04:12 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

5. postmortem Feb 02, 2026, 11:57 AM UTC

   **Investigation** The issue was detected at 12:14 PM CET on January 29, 2026, when Document Agents and AI Assistant services began experiencing degraded performance across the West Europe production environments \(Production 0, Production 1, and Production 5\). The engineering team began an immediate investigation after observing a pattern of failed requests and error responses affecting the document agent functionality. The root cause was a service interruption in the OpenAI services running on our cloud provider, Microsoft Azure. **Mitigation** The team worked to contain the impact by closely monitoring service health and coordinating with Microsoft. **Resolution** By 2:35 PM CET on January 29, 2026, Microsoft had restored stability in the affected region. As the platform stabilized, Document Agents in West Europe \(Production 0\), West Europe \(Production 1\), and West Europe \(Production 5\) returned to normal operation and full functionality was restored. **Impact and Scope** This incident affected Document Agent and AI Assistant functionality for tenants in West Europe \(Production 0\), West Europe \(Production 1\), and West Europe \(Production 5\) between 12:14 PM CET and 2:35 PM CET on January 29, 2026. Users experienced intermittent availability issues during this period. The issue was isolated to these clusters and did not impact other regions.

Read the full incident report →

Started Jan 29, 2026, 11:14 AM UTC· resolved Jan 29, 2026, 11:56 AM UTC

1. identified Jan 29, 2026, 11:14 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. resolved Jan 29, 2026, 11:56 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

3. postmortem Feb 02, 2026, 11:54 AM UTC

   **Investigation** The issue began at 11:05 AM CET on January 29, 2026, following a deployment to West Europe \(Production 0\). From that point, some users were unable to access the content library in both the Web Add-in and VSTO Add-in. The engineering team initiated an immediate investigation and quickly traced the issue to recent changes made to enhance the end-user experience. We found that the update caused an issue during application startup, which prevented the feature from loading correctly. **Mitigation** Upon identifying the likely cause, the team prioritized restoring access to the content library for affected users. After confirming the issue stemmed from the new changes, the team prepared a rollback of the deployment to remove the problematic update. **Resolution** To resolve the issue, the team rolled back the earlier deployment in West Europe \(Production 0\) at 12:49 PM CET on January 29, 2026. Once the rollback was completed, access to the content library in both the web add-in and VSTO returned to normal for all affected users. **Post-Incident Actions** To prevent similar issues in the future, we are introducing a new end-to-end test to simulate delayed environment initialization, making it easier to detect these types of timing-related problems before updates go live. **Impact and Scope** This incident affected a subset of users in West Europe \(Production 0\) who were unable to access the content library in the web add-in and VSTO between 11:05 AM CET and 12:49 PM CET on January 29, 2026. Other clusters and features were not impacted. ‌ We sincerely apologize for the disruption this incident caused. Ensuring a stable and reliable experience is always our top priority. We remain committed to continuous improvement and appreciate your understanding.

Read the full incident report →

Started Jan 27, 2026, 10:44 AM UTC· resolved Jan 27, 2026, 07:44 PM UTC

1. identified Jan 27, 2026, 10:44 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. We are impacted by an Open AI service availability in Azure, due to this some request using Document Agents and Ai Assistant could experience degraded performance. Further updates will be posted here soon.

2. identified Jan 27, 2026, 10:57 AM UTC

   Microsoft has reported the issue on their status page: https://azure.status.microsoft/en-gb/status

3. monitoring Jan 27, 2026, 05:34 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance.

4. resolved Jan 27, 2026, 07:44 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

5. postmortem Jan 31, 2026, 01:19 PM UTC

   _**Investigation**_ The issue was detected at 10:22 AM CET on January 27, 2026, when Document Agents and AI Assistant services began experiencing degraded performance across the West Europe production environments \(Production 0, Production 1, and Production 5\). _The engineering team began an immediate investigation after observing a pattern of failed requests and error responses affecting the document agent functionality._ The root cause was a service interruption in the OpenAI services running on our cloud provider, Microsoft Azure. _**Mitigation**_ _The team worked to contain the impact by closely monitoring service health and coordinating with Microsoft._ _**Resolution**_ _By 6:37 PM CET on January 27, 2026, Microsoft had restored stability in the affected region. As the platform stabilized, document agents in West Europe \(Production 0\), West Europe \(Production 1\), and West Europe \(Production 5\) returned to normal operation and full functionality was restored._ _**Impact and Scope**_ _This incident affected Document Agent_ and AI Assistant _functionality for tenants in West Europe \(Production 0\), West Europe \(Production 1\), and West Europe \(Production 5\) between 10:22 PM CET and 6:37 PM CET on January 27, 2026. Users experienced intermittent availability issues during this period. The issue was isolated to these clusters and did not impact other regions._

Read the full incident report →

Started Dec 17, 2025, 08:19 AM UTC· resolved Dec 17, 2025, 03:04 PM UTC

1. identified Dec 17, 2025, 08:54 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. monitoring Dec 17, 2025, 09:12 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. resolved Dec 17, 2025, 03:04 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Dec 22, 2025, 09:04 AM UTC

   **Investigation** The incident began on December 17, 2025, at 9:19 AM CET, when users experienced noticeable slowness while accessing the West Europe \(Production 1\) environment. The issue was detected at 9:28 AM CET through monitoring alerts indicating elevated SQL CPU utilization in the Templafy Hive environment. The engineering team initiated an investigation immediately upon detection. Early analysis focused on recent application-level changes and database behavior that could influence query execution and performance. As part of this process, the team reviewed active feature flags and identified a recently enabled query-related optimization as a potential contributing factor. At approximately 9:30 AM CET, the team disabled the identified feature flag as an initial mitigation step. However, SQL CPU utilization remained elevated, indicating that additional factors were contributing to the degradation. Further investigation into database telemetry and query execution behavior showed that, under certain data conditions, the SQL engine intermittently selected inefficient execution plans. These plans significantly increased CPU consumption and contributed to the observed performance impact. **Mitigation** When the initial feature flag rollback did not sufficiently reduce database load, the engineering team proceeded with infrastructure-level mitigation. At 9:45 AM CET, the SQL Elastic Pool was initially scaled up to increase available capacity. This action resulted in a short-term improvement; however, CPU contention reoccurred shortly afterward. To fully stabilize the environment, a second scaling operation was performed at 10:04 AM CET, increasing database and elastic pool capacity further. This action successfully alleviated CPU pressure and restored stable performance across the affected environment. **Resolution** By 10:06 AM CET on December 17, 2025, platform responsiveness had returned to normal for users in West Europe \(Production 1\). Continued monitoring following the second scaling operation confirmed that SQL CPU utilization remained within healthy thresholds and no further degradation was observed. The incident was considered fully resolved once sustained stability was verified. **Post-Incident Actions** The engineering team is taking several follow-up actions to reduce the likelihood and impact of similar incidents in the future: * Implementing database schema and query improvements to reduce the risk of inefficient execution plans under high-load scenarios. * Adjusting feature flag rollout practices to ensure more gradual exposure when testing query-related changes. * Evaluating controlled operational mechanisms to safely address problematic query execution behavior when necessary, with appropriate auditability and approvals. These actions aim to strengthen system resilience and improve response efficiency. **Impact and Scope** This incident affected a subset of users accessing the West Europe \(Production 1\) cluster. Impacted users experienced intermittent slowness while interacting with the platform during the incident window. No data loss was observed, and the issue was isolated to this single production cluster.

Read the full incident report →

Started Dec 12, 2025, 08:59 AM UTC· resolved Dec 16, 2025, 10:37 AM UTC

1. identified Dec 12, 2025, 08:59 AM UTC

   Due to a DNS update, a subset of end users might experience security prompt regarding SSL certificates on accessing Templafy. We have identified the issue and are working towards a resolution. Further updates will be posted here soon.

2. monitoring Dec 12, 2025, 09:44 AM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

3. monitoring Dec 15, 2025, 08:48 AM UTC

   We are continuing to monitor for any further issues.

4. resolved Dec 16, 2025, 10:37 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

5. postmortem Dec 17, 2025, 03:18 PM UTC

   **Investigation** On December 12, 2025, at 09:11 AM CET, a subset of users began experiencing issues when accessing Templafy Hive and Templafy One. The incident was detected at 09:19 AM CET by our internal monitoring and alerting systems. Users experienced symptoms such as security certificate warnings, applications not loading as expected, and issues with VSTO Add-ins. The engineering team immediately began investigating. Further analysis confirmed that a DNS migration introduced an issue that affected how the [templafy.com](http://templafy.com/) domain was resolved, which temporarily prevented users from reaching Templafy services correctly. ‌ **Mitigation** At 09:35 AM CET, the engineering team corrected the configuration change and restored it to a valid and stable state. This action stopped further impact for users accessing the services after that time. Because internet access settings can be cached locally, recovery times varied between users depending on their network environment. The team actively monitored service availability and access patterns to ensure stabilization. ‌ **Resolution** Following the configuration correction, Templafy Hive and Templafy One recovered automatically for most users. By 10:44 AM CET on December 12, 2025, the majority of affected users had regained access. Some users of VSTO Add-ins required manual steps locally before full functionality was restored. Monitoring continued after recovery to confirm that all services were operating normally and no further issues were observed. ‌ **Post-Incident Actions** To reduce the likelihood of similar incidents in the future, we are implementing the following improvements: * Additional approval and validation steps will be introduced for changes that can affect how users access Templafy services. * Clear ownership and responsibility will be established for managing critical configuration areas to ensure changes are reviewed and verified before being applied. These actions strengthen our safeguards around operational changes and reduce the risk of unintended impact. ‌ **Impact and Scope** The incident affected a subset of users who accessed Templafy services between 09:11 AM CET and 09:35 AM CET on December 12, 2025, primarily users whose network settings required a fresh connection at that time. Impacted services included Templafy Hive, Templafy One, the Templafy website, status page, Templafy Desktop, and VSTO Add-ins. Users accessing the services outside of this time window were not impacted. We sincerely apologize for the disruption this incident caused. Providing a stable and reliable service is a top priority for us, and we are committed to continuously improving our processes to prevent similar situations in the future.

Read the full incident report →

Started Nov 06, 2025, 11:10 AM UTC· resolved Nov 06, 2025, 02:47 PM UTC

1. investigating Nov 06, 2025, 11:10 AM UTC

   We are currently investigating this issue.

2. investigating Nov 06, 2025, 12:09 PM UTC

   We are continuing to investigate this issue.

3. identified Nov 06, 2025, 12:54 PM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

4. monitoring Nov 06, 2025, 01:26 PM UTC

   The incident has been successfully mitigated, and our team is actively monitoring the situation to ensure ongoing stability and performance. We are observing the systems to prevent any further disruptions.

5. resolved Nov 06, 2025, 02:47 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

6. postmortem Nov 10, 2025, 02:25 PM UTC

   **Investigation** The incident was **first reported at 1:14 AM CET on November 5, 2025**, when a customer noticed that some users experienced failed package updates through Templafy Desktop. The incident was formally **created at 11:59 AM CET on November 6, 2025**, and the engineering team immediately initiated an investigation. Initial findings pointed to a recent release — Templafy Desktop Client version 3.11.0, which had been **promoted to the Stable track on Tuesday, November 4, 2025**. The investigation revealed that this version introduced an issue where the Templafy Desktop update process was always opening update package related files with read and write access while they were read-only, resulting in the update failing. **Mitigation** To limit user disruption, the engineering team promptly reverted all affected customers to the previous Stable version of the Templafy Desktop Client. This rollback restored update functionality. Validation was performed in collaboration with affected customers to confirm that package updates completed successfully after the reversion. **Resolution** Following the rollback, the issue was fully mitigated. Impacted users regained full access to Templafy packages once the Templafy Desktop daily automatic update occurred, or sooner if users performed a manual update. No further issues were detected after the rollback was completed. **Post-Incident Actions** To prevent similar regressions in future releases, the following measures will be implemented: • Add an alert mechanism for detecting Templafy Desktop client trace errors during the update process. • Investigate options for introducing a code security warning that flags improper permission access to file resources across all Desktop projects. **Impact and Scope** This incident affected users without write permissions running Templafy Desktop Client version 3.11.0 **promoted to the Stable channel on November 4, 2025**. The issue caused update failures when accessing Templafy-installed packages. All impacted users were restored to normal functionality after reverting to the prior Stable version. We sincerely apologize for the inconvenience caused by this issue. Maintaining a reliable and seamless user experience remains our highest priority. We are taking immediate steps to strengthen our validation processes and ensure continued service stability and security.

Read the full incident report →

Started Oct 29, 2025, 04:20 PM UTC· resolved Oct 30, 2025, 09:18 AM UTC

1. identified Oct 29, 2025, 04:20 PM UTC

   We have identified an issue that affects all customers. Further updates will be posted here soon.

2. identified Oct 29, 2025, 06:27 PM UTC

   We're currently investigating an issue affecting Library App builds. The issue is related to a wider Microsoft Azure outage. Our engineers are monitoring the situation and working to restore normal functionality as soon as possible.

3. monitoring Oct 29, 2025, 07:18 PM UTC

   Engineers are monitoring the recovery of Microsoft's Azure Front Door services, which is leading to gradual recovery of our services. Full access for all users is expected to resume gradually.

4. monitoring Oct 29, 2025, 08:31 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Oct 30, 2025, 09:18 AM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

6. postmortem Oct 31, 2025, 09:11 AM UTC

   **Investigation** The issue was detected at **5:09 PM CET on October 29, 2025**, when monitoring and user reports indicated a complete outage affecting the **Templafy Hive** application. The engineering team immediately began investigating and identified that the outage coincided with a **major Microsoft Azure incident** impacting **Azure Front Door and Networking Infrastructure** services. This outage caused disruptions in key platform dependencies, resulting in failures across both **Hive** and **Templafy One** environments. During the investigation, several mitigation strategies were explored to bypass Azure Front Door; however, the widespread nature of the cloud provider outage also affected internal build components, preventing successful deployments. **Mitigation** The engineering team initiated mitigation efforts aimed at reducing dependency on Azure Front Door by preparing temporary routing adjustments and evaluating possible bypass configurations. Despite these efforts, the Azure networking layer continued to experience instability, limiting the effectiveness of the mitigation steps. Before the workaround could be fully implemented, **Azure Front Door services began recovering**, allowing normal connectivity and operations to gradually resume. **Resolution** By **9:52 PM CET on October 29, 2025**, Microsoft had restored stability across Azure Front Door and related infrastructure components. Once recovery was confirmed, Templafy Hive operations returned to normal without additional intervention. Continuous monitoring verified that all services were fully operational, and no residual impact remained. **Post-Incident Actions** While the root cause was outside Templafy’s control, the engineering team identified opportunities to improve detection and response to third-party outages: * Introduce additional availability checks for external CDN and Front Door endpoints. **Impact and Scope** The outage affected **all customers using Templafy Hive and Templafy One**, due to dependencies on Azure’s networking and Front Door infrastructure. The impact was **global** across all production clusters during the Azure service interruption window between **5:09 PM CET and 9:52 PM CET** on **October 29, 2025**. We sincerely apologize for the disruption caused by this event. Although the issue originated from our cloud provider, we understand the importance of continuous reliability. We are reinforcing our monitoring and resilience strategies to minimize the impact of future third-party outages and maintain the dependable service our customers expect.

Read the full incident report →

Started Oct 29, 2025, 03:13 PM UTC· resolved Oct 29, 2025, 08:55 PM UTC

1. identified Oct 29, 2025, 03:13 PM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. identified Oct 29, 2025, 04:50 PM UTC

   The engineering team has provided a solution, but they are blocked from releasing it because of the major Microsoft Azure outage.

3. resolved Oct 29, 2025, 08:55 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Oct 31, 2025, 02:25 PM UTC

   **Investigation** On October 29, 2025, at **11:59 AM CET**, an issue began affecting customers in the Hive environment on **West Europe \(Production 0\)**. Users were unable to insert non-dynamic assets such as PowerPoint slides, Word templates, and Outlook assets in Office applications. The issue was **detected at 3:38 PM CET**, prompting an immediate investigation. Initial analysis focused on recent deployments and configuration changes in the asset insertion workflows. The engineering team identified that a recent update to the **UI/UX experience in the asset browsing functionality** had introduced a configuration that caused non-dynamic assets to be processed incorrectly, leading to the observed behavior. **Mitigation** Once the cause was identified, the engineering team initiated work to **correct the build configuration** and restore expected behavior. The process was temporarily delayed due to an **overlapping Microsoft Azure outage**, which impacted build and release pipelines and slowed deployment activities. Despite this external delay, the team worked diligently to validate and prepare the fix as soon as Azure services became stable again, minimizing downtime for affected customers. **Resolution** After Azure services were fully operational, the engineering team deployed the **corrected build configuration**, which restored proper handling of non-dynamic assets. By **10:00 PM CET on October 29, 2025**, full functionality was confirmed restored for all affected tenants in **West Europe \(Production 0\)**. Following the resolution, validation tests confirmed that asset insertion in PowerPoint, Word, and Outlook was functioning normally. **Post-Incident Actions** To strengthen reliability and prevent similar issues, the following actions are being implemented: 1. **Improve test coverage** across UI/UX asset management workflows. 2. **Separate GA and experimental UI/UX components** to isolate risks during development. 3. **Establish better local test environments** for VSTO and preview engine scenarios. 4. **Enhance integration testing readiness** to ensure all tenant configurations can be validated before release. **Impact and Scope** The incident affected customers hosted in **West Europe \(Production 0\)** using the Hive environment. Some users experienced errors or were unable to insert assets in Office applications until the configuration was corrected and services were fully restored. The issue was contained to this cluster and did not affect other production environments. We sincerely apologize for the disruption this caused. Maintaining a reliable and seamless user experience is our highest priority. We are taking the above steps to ensure stronger safeguards in testing and deployment processes to prevent recurrence of similar issues.

Read the full incident report →

Started Oct 27, 2025, 11:27 AM UTC· resolved Oct 27, 2025, 12:10 PM UTC

1. identified Oct 27, 2025, 11:27 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. The issue is that images from integrations are not showing previews, inserting the image is still working. Further updates will be posted here soon.

2. resolved Oct 27, 2025, 12:10 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

3. postmortem Oct 28, 2025, 10:07 AM UTC

   **Investigation** The issue began on Friday October 24, 2025, at 9:49 AM CET and was detected later that day at 3:57 PM CET, when users reported that image previews from integration libraries were not loading within add-ins in the Hive environment. Through analysis of recent changes and deployment logs, the team determined that a recent update related to slide collection previews had unintentionally disrupted the image preview functionality for content connectors. Specifically, the change introduced a missing mapping for previews to a newly required type, causing the affected previews to fail to render. **Mitigation** On Monday October 27, 2025, at 12:35 PM CET, the engineering team began implementing a code fix to restore the correct mapping for content connector previews. At 12:56 PM CET, the fix was packaged and prepared for release. The fix was first deployed to the West Europe \(Production 0\) cluster at 1:04 PM CET, where it was confirmed to restore the missing preview functionality. Following successful verification, the fix was rolled out to all remaining production clusters. **Resolution** By October 27, 2025, at approximately 1:15 PM CET, the fix had been successfully deployed across all production clusters. The functionality of image previews from integration libraries in the Hive environment was fully restored. Monitoring confirmed stability and normal operation across all clusters. **Post-Incident Actions** To prevent similar issues in the future, the engineering team has initiated the following improvements: * Introduce end-to-end tests that specifically cover preview display functionality for all asset types, including content connector previews. * Improve code resilience and type handling to better tolerate future changes in preview logic and asset handling. These measures will enhance reliability and reduce the risk of regressions during future updates. **Impact and Scope** The incident affected the display of image previews from integration libraries within add-ins in the Hive environment. The impact was limited to a subset of users across multiple production clusters. We sincerely apologize for the disruption this incident caused. Ensuring a stable and reliable experience is our top priority, and we are continuously improving our processes and test coverage to prevent similar issues in the future.

Read the full incident report →

Started Oct 22, 2025, 11:31 AM UTC· resolved Oct 22, 2025, 01:12 PM UTC

1. identified Oct 22, 2025, 11:31 AM UTC

   We have identified an issue that affects a subset of customers and are working towards a resolution. Further updates will be posted here soon.

2. identified Oct 22, 2025, 12:59 PM UTC

   We are continuing to work on a fix for this issue.

3. resolved Oct 22, 2025, 01:12 PM UTC

   The incident has been resolved, and further information will be provided in a postmortem shortly. We apologize for the impact to affected customers.

4. postmortem Oct 24, 2025, 11:14 AM UTC

   **Investigation** The incident began on **October 16, 2025, at 6:00 AM CET** and was detected on **October 22, 2025, at 10:40 AM CET** after users reported that the **Templafy Desktop onboarding flow** failed during manual login. Affected users encountered a blank screen after pressing Logout, logging in again, and then selecting Access Templafy. The engineering team initiated the investigation on **October 22, 2025, at 1:20 PM CET**. Early analysis confirmed that the issue primarily affected users whose **seamless single sign-on \(SSO\)** was not functioning, forcing them into the manual login path. Upon reviewing recent code updates and deployment history, the team identified a regression in the AddInManagement desktop frontend component, specifically within a React component responsible for handling user interaction state. **Mitigation** Once the issue was identified, engineers began implementing a targeted fix. The correction focused on adjusting the type handling logic for the interactive state within the affected React component. The updated package was deployed to production for validation. Testing confirmed that the onboarding flow and manual login process were restored, and users were again able to access Templafy Desktop without encountering a blank screen. **Resolution** By **2:33 PM CET on October 22, 2025**, the fix had been successfully deployed to production. Validation across multiple tenants confirmed that the login flow functioned correctly, regardless of whether SSO was available. The restoration of the onboarding process fully resolved the issue, and no further user reports were received after the fix was applied. **Post-Incident Actions** Following the incident, several actions have been planned and initiated to reduce the likelihood of similar issues recurring: * Add an automated test to cover this login flow and verify correct behavior in the onboarding process. * Set up automated alerts for AddInManagement frontend errors to enable faster detection and response. **Impact and Scope** The incident affected users across multiple tenants where seamless SSO was not active. These users experienced a blank screen during the Templafy Desktop onboarding process, preventing successful login. The issue did not impact other areas of the product or users with functional SSO configurations. Once the fix was deployed, all affected tenants confirmed that login functionality had been restored. We sincerely apologize for the disruption caused by this issue. Maintaining a reliable and seamless login experience remains a top priority, and the engineering team has already implemented additional safeguards to prevent similar issues in the future.

Read the full incident report →