Xink Outage History

Started Oct 13, 2026, 02:35 PM UTC· resolved Oct 14, 2026, 12:39 PM UTC

1. monitoring Oct 13, 2026, 02:35 PM UTC

   On 13 October between 08:58 and 10:16 BST (09:58–11:16 CEST), Xink UK services, including the web portal, Outlook add-in sync and signature images, were unavailable or intermittently unreachable. We have mitigated the issue: service was restored at 10:16 BST and has been stable since. We are monitoring closely while we put measures in place to prevent a recurrence. Root cause analysis is ongoing.

2. resolved Oct 14, 2026, 12:39 PM UTC

   On 13 October between 08:58 and 10:16 BST (09:58–11:16 CEST), Xink services in our UK data center were unavailable or intermittently unreachable, including the Admin Portal, Outlook add-in and signature images. Cause: A sudden spike in requests for signature images overloaded the image service in our UK data center. The failure then spread to the component that routes all traffic into the UK data center, making UK services unavailable until it was restarted. Resolution: Service was restored at 10:16 BST and has been stable since. On 14 October we increased the capacity of the image service in the data center. We apologize for the disruption this caused.

Read the full incident report →

Started Jun 27, 2026, 03:00 AM UTC· resolved Jun 27, 2026, 06:00 AM UTC

1. resolved Jun 30, 2026, 09:02 AM UTC

   Between Saturday 03:00–06:00 UTC, a Microsoft-initiated change caused a subset of our server-side workers to fail and restart. The resulting brief loss of worker availability impacted a small subset of customers across all regions, leading to mail deliverability issues, including NDRs for some outbound messages.

Read the full incident report →

Started May 26, 2026, 09:02 AM UTC· resolved May 26, 2026, 09:21 AM UTC

1. identified May 26, 2026, 09:02 AM UTC

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

2. resolved May 26, 2026, 09:21 AM UTC

   Preliminary Root cause: Unusually high spike in requests. Mitigation: We increased capacity to handle peak client load in the EU DC. Services are operating normally.

Read the full incident report →

Started May 20, 2026, 07:45 AM UTC· resolved May 20, 2026, 10:00 AM UTC

1. identified May 20, 2026, 09:54 AM UTC

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

2. resolved May 20, 2026, 10:00 AM UTC

   Root cause: A background maintenance job began at 9:15 and pushed the database into heavy load. The spike was driven by an unusually high volume of clicks from misconfigured settings.

Read the full incident report →

Started May 19, 2026, 07:45 AM UTC· resolved May 19, 2026, 09:49 AM UTC

1. identified May 19, 2026, 09:39 AM UTC

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

2. identified May 19, 2026, 09:42 AM UTC

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

3. resolved May 19, 2026, 09:49 AM UTC

   This incident has been resolved. Root cause: EU database capacity lagged behind growing client traffic. Mitigation: we scaled and updated to higher tier the EU managed database to handle the increased load. This will prevent latency issue in the future.

Read the full incident report →

Started Apr 03, 2026, 02:45 AM UTC· resolved Apr 03, 2026, 09:44 AM UTC

1. monitoring Apr 03, 2026, 09:37 AM UTC

   The error occurred because the client secret used by our service principal for the Azure AD (Microsoft Entra ID) integration had expired. A client secret acts as a password that allows our application to authenticate and communicate with Microsoft Entra ID. These secrets are intentionally configured to expire after a set period for security reasons. When the secret reached its expiration date, authentication attempts began failing with the error: "The provided client secret keys for app are expired." We have generated a new client secret and updated all affected systems. We scheduled the next renewal to prevent this from happening again.

2. resolved Apr 03, 2026, 09:44 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 01, 2026, 10:08 AM UTC· resolved Apr 02, 2026, 10:57 AM UTC

1. investigating Apr 01, 2026, 10:08 AM UTC

   We are currently investigating an issue affecting the performance of click data retrieval for some customers. In certain cases, large volumes of historical data may lead to slower response times or timeouts when accessing click analytics. The root cause relates to how detailed click data has been stored over many years. As data volumes have grown significantly, this now impacts query performance. Our team is actively working on a solution that will improve performance while maintaining the level of insight our customers expect. This may include optimizing how older data is stored and accessed. We will share further updates as we progress.

2. investigating Apr 01, 2026, 10:09 AM UTC

   We are continuing to investigate this issue.

3. resolved Apr 02, 2026, 10:57 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 03, 2026, 11:27 AM UTC· resolved Mar 03, 2026, 12:37 PM UTC

1. investigating Mar 03, 2026, 11:27 AM UTC

   Affected clients are seeing permanent delivery failures when sending emails, with the error: "messages undeliverable to one or more recipients." Our team is actively investigating and implementing fixes. We will share more details soon.

2. resolved Mar 03, 2026, 12:37 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 27, 2026, 03:28 AM UTC· resolved Feb 27, 2026, 08:07 AM UTC

1. investigating Feb 27, 2026, 03:28 AM UTC

   Clients may encounter connection issue with the add-in, showing "Error contacting Xink: HTTP error: 500" We are currently investigating this issue.

2. resolved Feb 27, 2026, 08:07 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 21, 2025, 08:52 AM UTC· resolved Dec 22, 2025, 02:35 AM UTC

1. resolved Dec 21, 2025, 08:52 AM UTC

   Between December 20, 2025, 16:00 UTC and 20:00 UTC and again December 21, 2025 00:39 UTC and 02:35 UTC, several clients with rerouting enabled, experienced Non-Delivery Reports (NDRs) or were unable to send emails due to a Spamhaus (Microsoft’s default spam service provider) blocklisting our US IP address. Our US IP address (US Data Center) was temporarily blocked by Spamhaus, which is used by Microsoft as its default spam filtering service. During this period, one of our mail rerouting servers became overloaded due to a high volume of queued messages, reaching its processing limit. This led to additional delivery delays and Non-Delivery Reports (NDRs) for some clients. Our Spamhous monitoring system triggered an alarm, allowing us to quickly identify the issue and request immediate removal from the blocklist. The IP was successfully removed from the Spamhaus blocklist December 20, 2025 at 20:00 UTC and December 21, 2025 at 02:35 UTC. We do not have direct control over this service, however we have been actively working with both Microsoft and Spamhaus to prevent such issues. Despite these ongoing efforts, the block was imposed again. We are currently communicating with SpamHaus regarding these incidents, but we have not had any success so far. We recommend that clients resend any affected emails that may not have been delivered during the disruption window. For the referance, this is an reply from Spamhous regarding this block: "The below IP is being delisted. ------------------------------------------ IP: 52.186.121.110 ------------------------------------------ However, in the same subnet, there are a significant number of spamming IPs and this has a detrimental effect on any other IPs nearby. The issue in this case is the neighbourhood and the real solution is for the provider to restrict the provisioning of their cloud resources to bad actors for short intervals. While this IP is being removed, we cannot rule out a repeat due to this egregious behaviour. You may wish to ask your cloud provider how they plan to combat this persistent abuse of resources." Recommended Solution: Switch to the Xink 365 Add-in To avoid similar disruptions in the future, we strongly recommend switching to the Xink 365 Add-in, which does not rely on email routing or Spamhaus. With the add-in: ✅ No reliance on email servers – signatures are applied directly in Outlook before sending. ✅ No risk of email filtering issues – no interaction with external spam blacklists. ✅ Instant updates – signatures are applied automatically without waiting for mail flow rules. Most of our clients have already switched and eliminated email delivery risks altogether. Our team can assist with the transition to ensure a seamless experience. We strongly encourage you to consider the 365 Add-in for a more reliable and future-proof email signature solution.

Read the full incident report →

Started Dec 04, 2025, 10:14 PM UTC· resolved Dec 05, 2025, 02:57 AM UTC

1. investigating Dec 04, 2025, 10:14 PM UTC

   Clients may encounter connection issue with the add-in, showing error 503. We are currently investigating this issue.

2. monitoring Dec 04, 2025, 10:18 PM UTC

   Applied updates for the add-in caused initial connection issue with Classic Outlook. Restarting the Outlook application will fix and restore the connection. Please advise users to restart their Outlook application to clear the error.

3. resolved Dec 05, 2025, 02:57 AM UTC

   Incident has been resolved

4. postmortem Dec 05, 2025, 02:57 AM UTC

   ## Description The Outlook 365 Add-in for Classic Outlook encountered connection issue \(Error 503\) where email signatures failed to load. ## Root Cause The issue was caused by an important update for the Add-in which requires Classic Outlook to restart in order to complete. ## Impact * **User Experience**: Add-in is not connecting and signatures are not inserted when composing emails. * **Business Impact**: No critical data loss or security issues. ## Resolution Users must restart Outlook app to clear the error and complete the Add-in update.

Read the full incident report →

Started Nov 07, 2025, 09:56 AM UTC· resolved Nov 08, 2025, 12:29 AM UTC

1. monitoring Nov 07, 2025, 09:56 AM UTC

   We are actively investigating reports of slow image loading when composing a new email. This is only specific to the Xink add-in in Outlook on the web. Initial analysis confirms the issue does not occur in Outlook Classic or the New Outlook preview. Affected users may experience delayed rendering of signature images, intermittent image load errors, or instances where images fail to load entirely. Evidence points to a performance degradation in the Microsoft API used by the add-in to retrieve signature assets in Outlook on the web.

2. monitoring Nov 08, 2025, 12:28 AM UTC

   Microsoft has published official details regarding this incident on the Microsoft 365 Service Health Dashboard (SHD) under ID EX1183800. Our investigation confirms that the issue originates from Microsoft’s services and is not related to the Xink platform. We’ll continue to monitor the situation, but no action is required from Xink customers at this time. For more information, please refer to Microsoft’s SHD. https://admin.cloud.microsoft/?source=applauncher#/servicehealth/:/alerts/EX1183800

3. resolved Nov 08, 2025, 12:29 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 03, 2025, 09:54 AM UTC· resolved Nov 03, 2025, 11:32 AM UTC

1. monitoring Nov 03, 2025, 09:54 AM UTC

   Due to SpamHouse (Microsoft's default spam service provider) blocking our US IP, between November 03, 2025 05:56:01 (UTC) and November 03, 2025 08:07:35, some of our clients with rerouting enabled received NDRs or were unable to send emails. Date Listed: November 03, 2025 05:56:01 (UTC) Date Removed: November 03, 2025 08:07:35 (UTC) One of our rerouting servers became overwhelmed with requests, resulting in delays for affected clients. We encourage clients to resend the affected email. Recommended Solution: Switch to the Xink 365 Add-in To avoid similar disruptions in the future, we strongly recommend switching to the Xink 365 Add-in, which does not rely on email routing or Spamhaus. With the add-in: ✅ No reliance on email servers – signatures are applied directly in Outlook before sending. ✅ No risk of email filtering issues – no interaction with external spam blacklists. ✅ Instant updates – signatures are applied automatically without waiting for mail flow rules. Most of our clients have already switched and eliminated email delivery risks altogether. Our team can assist with the transition to ensure a seamless experience. We strongly encourage you to consider the 365 Add-in for a more reliable and future-proof email signature solution.

2. resolved Nov 03, 2025, 11:32 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 29, 2025, 06:35 PM UTC· resolved Oct 30, 2025, 12:30 AM UTC

1. monitoring Oct 29, 2025, 06:35 PM UTC

   Some clients have reported that their Xink Outlook add-in is not loading, resulting in email signature not appearing when composing or sending emails. This issue has been identified as being caused by a Microsoft Azure service disruption, specifically related to “Azure Front Door - Connectivity Issues.” This is a Microsoft managed infrastructure problem, and we have no ability to address that. We are continuously monitoring Microsoft’s incident updates and will notify clients once services stabilize. https://azure.status.microsoft/en-us/status

2. resolved Oct 30, 2025, 08:26 AM UTC

   This incident has been resolved, below is a Preliminary PIR by Microsoft: https://app.azure.com/h/YKYN-BWZ/62eaae This is our Preliminary PIR to share what we know so far. After our internal retrospective is completed (generally within 14 days) we will publish a Final PIR with additional details. What happened? Between 15:45 UTC on 29 October and 00:05 UTC on 30 October 2025, customers and Microsoft services leveraging Azure Front Door (AFD) may have experienced latencies, timeouts, and errors. Affected Azure services include, but are not limited to: App Service, Azure Active Directory B2C, Azure Communication Services, Azure Databricks, Azure Healthcare APIs, Azure Maps, Azure Portal, Azure SQL Database, Azure Virtual Desktop, Container Registry, Media Services, Microsoft Copilot for Security, Microsoft Defender External Attack Surface Management, Microsoft Entra ID (Mobility Management Policy Service, Identity & Access Management, and User Management UX), Microsoft Purview, Microsoft Sentinel (Threat Intelligence), and Video Indexer. Customer configuration changes to AFD remain temporarily blocked. We will notify customers once this block has been lifted. While error rates and latency are back to pre-incident levels, a small number of customers may still be seeing issues and we are still working to mitigate this long tail. Updates will be provided directly via Azure Service Health. What went wrong and why? An inadvertent tenant configuration change within Azure Front Door (AFD) triggered a widespread service disruption affecting both Microsoft services and customer applications dependent on AFD for global content delivery. The change introduced an invalid or inconsistent configuration state that caused a significant number of AFD nodes to fail to load properly, leading to increased latencies, timeouts, and connection errors for downstream services. As unhealthy nodes dropped out of the global pool, traffic distribution across healthy nodes became imbalanced, amplifying the impact and causing intermittent availability even for regions that were partially healthy. We immediately blocked all further configuration changes to prevent additional propagation of the faulty state and began deploying a ‘last known good’ configuration across the global fleet. Recovery required reloading configurations across a large number of nodes and rebalancing traffic gradually to avoid overload conditions as nodes returned to service. This deliberate, phased recovery was necessary to stabilize the system while restoring scale and ensuring no recurrence of the issue. The trigger was traced to a faulty tenant configuration deployment process. Our protection mechanisms, to validate and block any erroneous deployments, failed due to a software defect which allowed the deployment to bypass safety validations. Safeguards have since been reviewed and additional validation and rollback controls have been immediately implemented to prevent similar issues in the future.

Read the full incident report →

Started Jun 11, 2025, 08:18 AM UTC· resolved Jun 11, 2025, 08:50 AM UTC

1. investigating Jun 11, 2025, 08:18 AM UTC

   We are currently investigating this issue.

2. resolved Jun 11, 2025, 08:50 AM UTC

   We already applied fixes. Please allow up to 30 minutes for the service to get to normal operation.

3. postmortem Jun 11, 2025, 11:37 AM UTC

   ## **Description** We experienced a temporary issue in our Azure Kubernetes Service \(AKS\) environment that affected the availability of key services due to a sudden increase in traffic. ## **Root Cause** A sudden and significant spike in access to EU Xink service led to increased demand on our infrastructure. As a result, some components in our Azure Kubernetes Service \(AKS\) cluster were unable to start due to insufficient available resources at the time. This caused delays in deploying services. ## **Impact** * Xink Portal inaccessible during incident * Signatures inaccessible during incident ## **Resolution** * **Immediate Action:** Increased the number of nodes in the AKS cluster to provide additional compute resources, allowing pending components to be scheduled and services to recover. * **Permanent Fix:** Adjusted auto-scaling thresholds and resource allocation policies to better handle sudden spikes in traffic without resource exhaustion. * **Deployment:** Applied configuration changes and resource scaling updates during the incident and validated them in production to ensure stability. * **Monitoring:** Post-resolution monitoring confirmed that all services are operating normally and resource levels remain healthy under load.

Read the full incident report →

Started May 07, 2025, 09:10 AM UTC· resolved May 07, 2025, 10:01 AM UTC

1. investigating May 07, 2025, 10:00 AM UTC

   We are investigating an issue where the Outlook 365 Add-in is experiencing delays in loading email signatures for some users.

2. resolved May 07, 2025, 10:01 AM UTC

   This incident has been resolved.

3. postmortem May 13, 2025, 12:19 PM UTC

   ## Description The Outlook 365 Add-in encountered an issue where email signatures failed to load promptly for a subset of users. The delay was noticeable when users opened the email composition window, causing a degraded user experience. The issue was reported by multiple users across different regions and was traced back to internal changes in how image URLs are processed within the add-in. ## Root Cause The issue was caused by recent internal changes to the image URL processing logic in the Outlook 365 Add-in. Specifically, a new validation step for image URLs introduced unintended latency when fetching signature images from external servers. ## Impact * **User Experience**: Delays in signature loading when composing emails. * **Business Impact**: No critical data loss or security issues. ## Resolution 1. **Immediate Action**: Deployed a temporary workaround to bypass the new URL validation step, reducing latency for affected users. 2. **Permanent Fix**: Rewrote the image URL processing logic to optimize performance and remove excessive validation checks. 3. **Deployment**: Rolled out the fix to production after thorough testing in a staging environment. 4. **Monitoring**: Post-deployment monitoring confirmed that signature loading times returned to normal.

Read the full incident report →

Started Nov 20, 2024, 02:30 PM UTC· resolved Nov 20, 2024, 03:15 PM UTC

1. identified Nov 20, 2024, 04:35 PM UTC

   Clients may experience issues accessing the Xink UK portal due to some services being unreachable or responding slowly. The problem originated from a scheduled automatic update that failed, impacting service availability. To address this issue, we scaled additional resources to restore functionality and improve service performance. We apologize for the inconvenience and appreciate your patience as we work to restore services to normal.

2. resolved Nov 20, 2024, 04:36 PM UTC

   This incident has been resolved.

Read the full incident report →