Update -

What happened?


Between 19:51 UTC on 07 September 2024 and 11:30 UTC on 10 September 2024, a platform issue resulted in an impact to the Azure Virtual Machines service. Customers may have experienced resource health status displayed incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may have resulted in inaccuracies in activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


 


What do we know so far?


We determined that a recent change resulted in an increase in traffic for multiple backend clusters supporting Virtual Machines. This issue led to inaccuracies in the health status of some resources, leading to potential incorrect or missed alerts. 


 


How did we respond?


  • 19:51 UTC on 07 September 2024 – Customer impact began.
  • 02:08 UTC on 08 September 2024 – We received customer reports that indicated this issue was impacting multiple resources. Initially, we were investigating isolated occurrences of this issue, however once we had the additional reports, we began further investigations.
  • 07:08 UTC on 09 September 2024 – The recent change to the service identified as a main contributing factor.
  • 09:28 UTC on 09 September 2024 – We performed scale-out operations to allow our service to handle increased load.
  • 09:45 UTC on 09 September 2024 – Our telemetry showed the service was healthy and we issued resolved communications.
  • 15:10 UTC on 09 September 2024 – We observed the issue reoccur. To bring full mitigation, we executed a rollback of the problematic change in accordance with our Safe Deployment Practices (SDP).
  • 11:30 UTC on 10 September 2024 – Service restored, and customer impact mitigated.

 


What happens next?


Our team will be completing an internal retrospective to understand the incident in more detail. Once that is completed, generally within 14 days, we will publish a Post Incident Review (PIR) to all impacted customers. To get notified when that happens, and/or to stay informed about future Azure service issues, make sure that you configure and maintain Azure Service Health alerts – these can trigger emails, SMS, push notifications, webhooks, and more: https://aka.ms/ash-alerts . For more information on Post Incident Reviews, refer to https://aka.ms/AzurePIRs . The impact times above represent the full incident duration, so are not specific to any individual customer. Actual impact to service availability may vary between customers and resources – for guidance on implementing monitoring to understand granular impact: https://aka.ms/AzPIR/Monitoring . Finally, for broader guidance on preparing for cloud incidents, refer to https://aka.ms/incidentreadiness . 


Sep 11, 2024 - 02:38 CEST
Update -

What happened?


Between 19:51 UTC on 07 September 2024 and 11:30 UTC on 10 September 2024, a platform issue resulted in an impact to the Azure Virtual Machines service. Customers may have experienced resource health status displayed incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may have resulted in inaccuracies in activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


 


This issue is now mitigated. An update with more information will be provided shortly.


Sep 11, 2024 - 02:00 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 7 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


 


Current Status: We have correlated this issue to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions.


 


We have completed our efforts to increase capacity and scale for our mitigation operations, and are making good progress in executing a rollback of the recent change in accordance with our Safe Deployment Practices (SDP). Many customers may already be experiencing signs of recovery when viewing the Resource Health status. We are progressing through affected regions, and expect the rollback to be complete within next 24 hours at which point all customer impact should be mitigated.


 


We will provide the next update in 12 hours, or sooner if events warrant.


Sep 10, 2024 - 19:43 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. 


We have completed our efforts to increase capacity and scale for our mitigation operations, and some customers may already be experiencing signs of recovery when viewing the Resource Health status. 


To ensure full recovery, we are executing a rollback of the recent change in accordance with our Safe Deployment Practices (SDP), and progress is going well. Since this will take some time, we will provide the next update in 5 hours, or sooner if events warrant.


Sep 10, 2024 - 15:51 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. 


We continue to increase capacity and scale for our mitigation operations, and some customers may already be experiencing improvements. 


To ensure full recovery, we are executing a rollback in accordance with our Safe Deployment Practices (SDP), and progress is going well. Since this will take some time, we will provide the next update in 10 hours, or sooner if events warrant.


Sep 10, 2024 - 11:50 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.




Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. We continue to increase capacity and scale for our mitigation operations, and some customers may already be experiencing improvements. To ensure full recovery, we are executing a rollback in accordance with our Safe Deployment Practices (SDP), and progress is going well. Since this will take some time, we will provide the next update within 4 hours, or sooner if necessary.


Sep 10, 2024 - 07:14 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.


 


Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. We continue to increase capacity and scale for our mitigation operations, as a result, customers should begin to notice some improvements. To ensure a full recovery, we are executing a rollback following our Safe Deployment Practices (SDP). Since this will take some time we will provide the next update within 4 hours, or sooner if necessary.


Sep 10, 2024 - 02:34 CEST
Update -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.




Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. We continue to focus on increasing capacity as we work on validating a roll back in accordance with our Safe Deployment Practices (SDP) for a complete recovery. Since this will take some time, we will provide the next update within 4 hours, or sooner if necessary.


Sep 09, 2024 - 23:23 CEST
Investigating -

Impact Statement: Starting at 19:51 UTC on 07 September 2024, you have been identified as a customer using Azure Virtual Machines whose resource health status may display incorrectly, indicating an 'unknown' status even though they may be healthy. This discrepancy in the health status may result in inaccuracies in your activity logs, potentially leading to incorrect alerts—either false alerts or missed alerts.




Current Status: In earlier communications, we indicated that this issue had been mitigated. However, our telemetry shows the issue has resurfaced. We have correlated this recurrence to a recent change that caused an increase in traffic for multiple backend scale unit supporting resource health metrics for Virtual Machines across several regions. We continue to focus on increasing capacity as we work on validating a roll back in accordance with our Safe Deployment Practices (SDP) for a complete recovery. Since this will take some time, we will provide the next update within 4 hours, or sooner if necessary.


Sep 09, 2024 - 23:02 CEST
Graphisoft ID Operational
90 days ago
99.87 % uptime
Today
Graphisoft License Delivery Operational
90 days ago
99.87 % uptime
Today
Graphisoft Store Operational
90 days ago
99.87 % uptime
Today
Graphisoft Legacy Store Operational
90 days ago
99.87 % uptime
Today
Graphisoft Legacy Webshop Operational
90 days ago
99.78 % uptime
Today
GSPOS Operational
90 days ago
100.0 % uptime
Today
Graphisoft BIM Components Operational
90 days ago
99.87 % uptime
Today
Graphisoft BIMx Transfer Operational
90 days ago
99.87 % uptime
Today
Graphisoft DevOps Components Operational
90 days ago
99.87 % uptime
Today
Microsoft Incidents Operational
90 days ago
99.87 % uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Past Incidents
Sep 15, 2024

No incidents reported today.

Sep 14, 2024

No incidents reported.

Sep 13, 2024

No incidents reported.

Sep 12, 2024

No incidents reported.

Sep 11, 2024

Unresolved incident: Microsoft Incident - Virtual Machines - Mitigated – Incorrect Resource Health Status for Azure Virtual Machines.

Sep 10, 2024
Sep 9, 2024
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 6, 03:59 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Update - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 8, 01:55 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 2, 05:58 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 8, 01:55 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Update - Metric Alert for sb-fcs-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 22, 03:57 CEST
Investigating - Metric Alert for sb-fcs-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 21, 13:57 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 24, 03:56 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 27, 12:22 CEST
Resolved - This incident has been resolved.
Sep 9, 10:05 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 27, 12:22 CEST
Resolved - This incident has been resolved.
Sep 9, 10:04 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Aug 27, 12:22 CEST
Resolved - This incident has been resolved.
Sep 9, 10:04 CEST
Investigating -

What happened?


Between 07:30 UTC and 15:37 UTC on 22 April 2024, a subset of customers using Azure Front Door (AFD) experienced intermittent availability drops, connection timeouts and increased latency in UAE North and Qatar Central. Approximately 18% of traffic that was served by AFD in the region was affected during the impact window.


What went wrong and why?


The issue was triggered by a 10x regional traffic surge, which caused a high CPU utilization within specific AFD Points of Presence (POPs) and in turn an availability loss for AFD customers near the UAE North and Qatar Central regions.


  • Normally, automatic traffic shaping, and other mechanisms work to shed load away from overloaded AFD environments.
  • In this case, traffic shaping did activate and shifted normal traffic away, but some AFD environments remained overloaded due to the fact that the surge traffic did not honor DNS record TTLs and customer’s traffic stayed on these overloaded environments for much longer than the configured DNS TTL.
  • In addition to traffic shaping, AFD also has mechanisms in place that protect the AFD platform from traffic surges. These platform protections were also overloaded during this incident due to an undiscovered regression and geographically concentrated nature of the traffic.
  • While automated monitors identified the issue nearly immediately, impact was prolonged because of alert with configured with too-low severity and the lack of mitigation processes for floods of this type.

How did we respond?


  • 07:20 UTC on 22 April 2024: There was an unexpected increase in customer traffic near Azure Front Door's DOH point-of-presence.
  • 07:28 UTC: As traffic volume increased, AFD's automatic traffic shaping mechanisms activated to distribute the load. Platform protections also began rate limiting the surge traffic due to the fact that it exceeded the default traffic quotas for AFD.
  • 07:55 UTC: Internal monitoring triggered a low-level alert due to high CPU in the region.
  • 11:33 UTC: Availability monitors crossed thresholds necessary to trigger a high-level alert and on-call engineers were engaged.
  • 12:18 UTC: The source of the surge traffic was identified, and engineers applied mitigations to reduce impact to other customers.
  • 15:37 UTC: Our telemetry confirmed that the issue was mitigated, and service functionality was fully restored.

How are we making incidents like this less likely or less impactful?

  • We have already updated our platform to protect against traffic that does not respond to normal traffic shaping. We have also clarified our updated processes to mitigate traffic floods of this type (Completed).
  • Adjust our regional availability instrumentation thresholds to properly alert of the severity of issues (Estimated completion: August 2024).
  • In the longer term, we are working to improve our resilience testing for scenarios such as this and improve noisy-neighbor protections to isolate anomalous traffic (Estimated completion: CY24-Q4).

How can we make our incident communications more useful?

You can rate this PIR and provide any feedback using our quick 3-question survey


Jul 2, 21:20 CEST
Resolved - This incident has been resolved.
Sep 9, 10:03 CEST
Update -

Impact Statement: Between 22:43 UTC on 19 June 2024 and 22:35 UTC on 29 July 2024, you were identified among a subset of customers using Multi-Factor Authentication (MFA) who may have experienced issues with sign-in logs for MFA. Some MFA sign-in attempts' final error results were not visible in the Microsoft Entra ID Sign-In logs. This issue was observed in the Azure Portal, MSGraph API, and Log Analytics. We identified that this issue was a result of a configuration change introduced in a recent deployment.


Mitigation: We deployed a hotfix to mitigate the issue. We monitored the service following the hotfix deployment to validate the mitigation.


Next Steps: We will review our deployment procedures and testing procedures to prevent future occurrences. Stay informed about Azure service issues by creating custom service health alerts: https://aka.ms/ash-videos  for video tutorials and https://aka.ms/ash-alerts  for how-to documentation.


Jul 30, 02:45 CEST
Update -

Impact Statement: Starting at 22:43 UTC on 19 June 2024, you have been identified among a subset of customers using Multi-Factor Authentication (MFA) who may be experiencing issues with sign-in logs for MFA. Some MFA sign-in attempts' final error results are not visible in the Microsoft Entra ID SignIn logs. This issue is ongoing in the Azure Portal, MSGraph API, and Log Analytics. These sign-in logs would show as "interrupted" in the Azure Portal. The AuthenticationDetails tab will still display what MFA steps were attempted. If the multifactor authentication attempt succeeded, the AuthenticationDetails will indicate this as well. We identified that this issue was a result of a configuration change introduced in a recent deployment.




Current status: We are deploying the hotfix following our extended Safe Deployment Practices (SDP) procedures to prevent any disruption to the service, which is taking more time than anticipated. The next update will be provided at 20:00 UTC on 31 July 2024 or as events warrant.


Jul 23, 20:48 CEST
Update -

Impact Statement: Starting at 22:43 UTC on 19 June 2024, you have been identified among a subset of customers using Multi-Factor Authentication (MFA) who may be experiencing issues with sign-in logs for MFA. Some MFA sign-in attempts' final error results are not visible in the Microsoft Entra ID SignIn logs. This issue is ongoing in the Azure Portal, MSGraph API, and Log Analytics. These sign-in logs would show as "interrupted" in the Azure Portal. The AuthenticationDetails tab will still display what MFA steps were attempted. If the multifactor authentication attempt succeeded, the AuthenticationDetails will indicate this as well. We identified that this issue was a result of a configuration change introduced in a recent deployment.


 


Current Status: Hotfix has been prepared and is currently being deployed following our Safe Deployment Practices. The next update will be provided 20:00 UTC on 23 July 2024 or as events warrant.


Jul 20, 21:47 CEST
Update -

Impact Statement: Starting at 22:43 UTC on 19 June 2024, you have been identified among a subset of customers using Multi-Factor Authentication (MFA) who may be experiencing issues with sign-in logs for MFA. Some MFA sign-in attempts' final error results are not visible in the Microsoft Entra ID SignIn logs.


This issue is ongoing in the Azure Portal, MSGraph API, and Log Analytics. We determined this issue was caused by a configuration change introduced in a recent deployment.


These sign-in logs would show as "interrupted" in the Azure Portal. The AuthenticationDetails tab will still display what MFA steps were attempted. If the multifactor authentication attempt succeeded, the AuthenticationDetails will indicate this as well. We identified that this issue was a result of a configuration change introduced in a recent deployment.


Current Status: We are preparing a hotfix that will be deployed to mitigate this issue. The next update will be provided 20:00 UTC on 20 July 2024 or as events warrant.


Jul 18, 21:47 CEST
Investigating -

Engineers are investigating an alert for Multi-Factor Authentication (MFA). More information will be provided in 60 minutes or as events warrant.


Jul 18, 20:50 CEST
Resolved - This incident has been resolved.
Sep 9, 10:03 CEST
Investigating - Metric Alert for sb-idp-prod-euw-001 - the maximum Count of dead-lettered messages in a Queue/Topic is greater than equal to 10.
Jul 3, 14:04 CEST
Resolved - This incident has been resolved.
Sep 9, 10:03 CEST
Update -

What happened?


Between 23:52 UTC on 11 June 2024 and 02:10 UTC on 12 June 2024 and Between 23:30 UTC on 13 June 2024 and 00:24 UTC on 14 June 2024, a platform update resulted in an impact to the following services.


• Azure Front Door: Customers may have experienced intermittent issues with latency and timeouts in Japan East.


• Azure CDN: Customers experienced intermittent issues with latency and timeouts.




What went wrong and why?


To comply with the continuously evolving security and compliance landscape, we follow a continuous security patch lifecycle. The patches upgrade the versions of all components and libraries that power our infrastructure. The patches are qualified in lab environments and rolled out following a safe deployment practice. During the patch process, nodes are taken offline to prevent disruption due to ongoing patches and are brought back into rotation after synthetic health probes give us a positive signal.




As Azure Front Door provides content caching and forwarding abilities, it needs to maintain warm connections to other services within the system and to the origins. The most recent security patches reduced the connection limit between systems, and typically when this behavior occurs our load balancing mechanism will balance traffic to over other systems. Although, there was previously an unknown bug with this load balancing mechanism, and it did not recognize the systems being patched had exhausted their connection limits.




This bug was first observed on the 11th of June 2024 when we were performing patching, but we attributed the issues to needing more capacity, and as such the problem was mitigated when capacity was added. Subsequently on the 13th of June 2024 during a security patch rollout we were notified that a customer was impacted again with intermittent issues with latency and timeouts, and it was discovered during this timeframe of the bug noted above.




Moreover, it was identified our current patch qualification system does not simulate all load conditions to test peak limits, thus we failed to identify the reduction in available connection limits.




How did we respond?


• 00:46 UTC on 11 June 2024 - Japan East POP taken offline for security patches


• 23:00 UTC on 11 June 2024 - Japan East POP brought online


• 23:52 UTC on 11 June 2024 - Customer impact started.


• 00:18 UTC on 12 June 2024 - Issue was detected via service monitoring alerts.


• 00:26 UTC on 12 June 2024 - We traced the source of this issue to a scheduled maintenance.


• 01:58 UTC on 12 June 2024 - We adjusted load management configuration to balance the traffic in the region.


• 02:10 UTC on 12 June 2024 - Service(s) restored, and customer impact mitigated.


• 04:47 UTC on 12 June 2024 - Customers notified of the outage (Mitigated)


• 21:00 UTC on 13 June 2024 - Added additional capacity in Japan East to address load concerns.


• 21:30 UTC on 13 June 2024 - Traffic ramp-up started in Japan East POP


• 23:30 UTC on 13 June 2024 – Customer impact began.


• 23:37 UTC on 13 June 2024 – Issue was detected via Service monitoring


• 00:02 UTC on 14 June 2024 – contributing cause factor identified.


• 00:24 UTC on 14 June 2024 – Mitigation workstream started.


• 00:34 UTC on 14 June 2024 – Service restored, and customer impact mitigated


• 02:39 UTC on 14 June 2024 – Customers notified of the outage (Mitigated)




How are we making incidents like this less likely or less impactful?


We have identified several key repair items to prevent and mitigate against similar issues, and we are confident these repairs will prevent such incidents. Although as noted below, since it will take several months to implement these repairs, we have implemented processes that will prevent issues during security patches.




• We have already identified the root-cause and applied fixes to ensure all POPs have sufficient connection limits (Completed).


• We are improving our monitoring to add metrics for active connections in use (Estimated completion: Q4-CY24).


• We are adding intelligence in traffic load management to automatically shift traffic based on active connections in use (Estimated completion: Q4-CY24)


• We are improving our procedures to run load tests in patch qualification (Estimated completion: Q4-CY24).


• We are improving our notification procedures to proactively inform customers of availability impact (Estimated completion: Q4-CY24).


• In the longer term, we will address validation gaps in our procedures to bring POPs online (Estimated completion: Q4-CY24).




How can we make our incident communications more useful?


You can rate this PIR and provide any feedback using our quick 3-question survey: https://aka.ms/AzPIR/XKDP-DTG


Jul 3, 11:59 CEST
Update -

What happened?


Between 23:52 UTC on 11 June 2024 and 02:10 UTC on 12 Jun 2024, a planned maintenance resulted in an impact to the following services Japan East.


  • Azure Frontdoor : Customers may have experienced intermittent issues with latency and timeouts.
  • Azure CDN: Customers may have experienced intermittent issues with latency and timeouts.

 




What do we know so far?


We have traced the source of this issue to a scheduled maintenance. This resulted in some major traffic changes among the regions.




 


How did we respond?


  • 23:52 UTC on 11 June 2024 - Customer impact began.
  • 00:18 UTC on 12 Jun 2024 - Issue was detected via service monitoring alerts.
  • 00:26 UTC on 12 Jun 2024 - We traced the source of this issue to a scheduled maintenance.
  • 01:58 UTC on 12 JUN 2024 - We adjusted load management configuration to balance the traffic in the region.
  •  02:10 UTC on 12 Jun 2024 - Service(s) restored, and customer impact mitigated.

 


What happens next?

  • To request a Post Incident Review (PIR), impacted customers can use the “Request PIR” feature within Azure Service Health. (Note: We're in the process of transitioning from "Root Cause Analyses (RCAs)" to "Post Incident Reviews (PIRs)", so you may temporarily see both terms used interchangeably in the Azure portal and in Service Health alerts.)
  • To get notified if a PIR is published, and/or to stay informed about future Azure service issues, make sure that you configure and maintain Azure Service Health alerts – these can trigger emails, SMS, push notifications, webhooks, and more: https://aka.ms/ash-alerts .
  • For more information on Post Incident Reviews, refer to https://aka.ms/AzurePIRs .
  • Finally, for broader guidance on preparing for cloud incidents, refer to https://aka.ms/incidentreadiness .



Jun 12, 07:39 CEST
Investigating -

What happened?


Between 23:52 UTC on 11 June 2024 and 02:10 UTC on 12 Jun 2024, a platform update resulted in an impact to the following services.


  • Azure Frontdoor : Customers may have experienced intermittent issues with latency and timeouts in Japan East.
  • Azure CDN: Customers experienced intermittent issues with latency and timeouts.

 


This issue is now mitigated, more information will be provided shortly.


Jun 12, 06:48 CEST
Sep 8, 2024

No incidents reported.

Sep 7, 2024

No incidents reported.

Sep 6, 2024

No incidents reported.

Sep 5, 2024

No incidents reported.

Sep 4, 2024

No incidents reported.

Sep 3, 2024

No incidents reported.

Sep 2, 2024

No incidents reported.

Sep 1, 2024

No incidents reported.