Octopus Outage History

Started Oct 22, 2026, 05:17 PM UTC· resolved Oct 22, 2026, 07:02 PM UTC

1. monitoring Oct 22, 2026, 05:17 PM UTC

   While Octopus is not directly affected, Octopus instances with pipelines or configurations that rely on GitHub may experience on-screen errors, failed deployments, and other subsequent issues due to the current GitHub outage. For more information about the GitHub outage, please visit: https://www.githubstatus.com We are monitoring for further reports and will update if information comes available.

2. resolved Oct 22, 2026, 07:02 PM UTC

   According to GitHub, their services have resumed normal operation. You can find out more by visiting: https://www.githubstatus.com

Read the full incident report →

Started Oct 05, 2026, 03:48 PM UTC· resolved Oct 05, 2026, 11:56 PM UTC

1. investigating Oct 05, 2026, 03:48 PM UTC

   Currently investigating

2. investigating Oct 05, 2026, 03:53 PM UTC

   We're currently investigating this issue.

3. investigating Oct 05, 2026, 04:46 PM UTC

   We're currently investigating this issue. This appears to only have affected a few instances.

4. monitoring Oct 05, 2026, 05:06 PM UTC

   This issue appears to have been intermittent and likely caused by an external service. We're currently monitoring for further reports.

5. resolved Oct 05, 2026, 11:56 PM UTC

   We've identified and resolved an issue (https://github.com/OctopusDeploy/Issues/issues/10288) that resulted in users being unable to view the audit log page. This is fixed from 2026.4.6234.

Read the full incident report →

Started Jul 31, 2026, 01:32 PM UTC· resolved Jul 31, 2026, 03:04 PM UTC

1. investigating Jul 31, 2026, 01:32 PM UTC

   We are currently investigating issues with our certificate for https://g.octopushq.com. Customers may see issues with build servers trying to download the CLI using V5 and below build server steps. Customers may also see issues with octopus.com.

2. monitoring Jul 31, 2026, 02:02 PM UTC

   We have identified and mitigated the certificate issues for https://g.octopushq.com. Customers should now be able to download the CLI using V5 and below build server steps. Any certificate issues with octopus.com should now be resolved. Please email [email protected] if you are still seeing issues, we will continue to monitor this over the next few hours.

3. resolved Jul 31, 2026, 03:04 PM UTC

   This issue has now been resolved. Thank you for your patience whilst we investigated the incident. If you are having any further issues please email [email protected].

Read the full incident report →

Started Jul 23, 2026, 04:08 PM UTC· resolved Jul 23, 2026, 08:28 PM UTC

1. identified Jul 23, 2026, 04:08 PM UTC

   Due to upstream Azure issues in the West US region, some services may have no or intermittent connectivity. We are continuing to monitor the impact on our systems.

2. identified Jul 23, 2026, 04:09 PM UTC

   Known impacted services: - The Octopus.com blog

3. monitoring Jul 23, 2026, 06:35 PM UTC

   Azure's mitigation has allowed access to the impacted services. We will continue to monitor service availability.

4. resolved Jul 23, 2026, 08:28 PM UTC

   Azure has resolved this issue.

Read the full incident report →

Started Jul 03, 2026, 12:25 AM UTC· resolved Aug 04, 2026, 12:23 PM UTC

1. identified Jul 03, 2026, 12:25 AM UTC

   We have identified an issue in Octopus Server 2026.3.4658 or later when existing Bicep deployments may start failing. We have a public issue tracking this with a workaround https://github.com/OctopusDeploy/Issues/issues/10129 We are working on a fix and will update this incident and the public issue when it's resolved.

2. resolved Aug 04, 2026, 12:23 PM UTC

   The fix has been live across all Octopus Cloud servers for several weeks now without further issues.

Read the full incident report →

Started May 29, 2026, 06:10 AM UTC· resolved May 30, 2026, 12:38 AM UTC

1. monitoring May 29, 2026, 06:10 AM UTC

   Our upstream provider, Azure in West US2, is currently experiencing an issue which might be affecting your ability to deploy. We will resolve this incident once we have received confirmation the issue has been resolved from our upstream provider.

2. resolved May 30, 2026, 12:38 AM UTC

   Our upstream provider, Azure in West US2, has resolved their issue. While the issue was ongoing, some Octopus Cloud instances in West US2 may have experienced brief downtime and network communication issues. For more details, see Azure's incident report (Tracking ID: GHRP-84G) at https://azure.status.microsoft/en-us/status/history/.

Read the full incident report →

Started May 15, 2026, 12:36 PM UTC· resolved May 18, 2026, 10:49 AM UTC

1. identified May 15, 2026, 12:36 PM UTC

   We have identified the issue and are working on a fix. If you are experiencing this please see the Github issue below for workarounds - https://github.com/OctopusDeploy/Issues/issues/10026

2. resolved May 18, 2026, 10:49 AM UTC

   We have pushed out a fix for this issue and it should be rolling out to Octopus Cloud customers over the next few days. Please contact [email protected] if you are seeing this issue and we can arrange to get your instance upgraded.

Read the full incident report →

Started May 05, 2026, 01:18 PM UTC· resolved May 07, 2026, 06:40 AM UTC

1. identified May 05, 2026, 01:18 PM UTC

   We have observed issues provisioning Dynamic Workers in our West US 2 region. We are working on mitigations and monitoring. A small number of customers have experienced lease failures.

2. identified May 05, 2026, 01:25 PM UTC

   We are in the process of switching Octopus Cloud instances in the West US 2 region to use dynamic workers in our standby region (Central US). Customers who have experienced leasing failures should retry their deployments or runbook runs.

3. monitoring May 05, 2026, 01:43 PM UTC

   We have completed switching Octopus Cloud instances in the West US 2 region to use dynamic workers in our standby region (Central US). This should mitigate this issue for all customers. We will update this incident when dynamic workers in West US 2 are stable and we have reverted all Cloud instances back to using workers in West US 2.

4. monitoring May 07, 2026, 12:51 AM UTC

   We are continuing to monitor for any further issues.

5. resolved May 07, 2026, 06:40 AM UTC

   We have not observed any further issues in the West US 2 region so all Octopus Cloud instances in the West US 2 region are using dynamic workers in West US 2 once again.

Read the full incident report →

Started Apr 01, 2026, 08:06 AM UTC· resolved Apr 08, 2026, 04:11 AM UTC

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

   We are aware of an issue affecting Octopus Cloud customers running deployments that interact with AWS, including EKS/Kubernetes targets and AWS health checks. Impacted customers may see authentication errors when running these deployments. Our team is actively investigating and working to resolve the issue. Workaround: If you are affected, adding your AWS region as an environment variable in your script steps may resolve the issue: export AWS_REGION= for Bash $env:AWS_REGION = "" for Powershell E.g export AWS_REGION=ap-southeast-2 $env:AWS_REGION = "ap-southeast-2" We apologise for the disruption and will share further updates as our investigation progresses. If you need help in the meantime, please contact us at [email protected]

2. investigating Apr 01, 2026, 08:36 AM UTC

   We are aware of an issue affecting Octopus Cloud customers running deployments that interact with AWS, including EKS/Kubernetes targets and AWS health checks. Impacted customers may see authentication errors when running these deployments. Our team is actively investigating and working to resolve the issue. Workaround: If you are affected, adding your AWS region as an environment variable in your script steps may resolve the issue: export AWS_REGION=[REGION] for Bash $env:AWS_REGION = "[REGION]" for Powershell E.g export AWS_REGION=ap-southeast-2 $env:AWS_REGION = "ap-southeast-2" We apologise for the disruption and will share further updates as our investigation progresses. If you need help in the meantime, please contact us at [email protected]

3. resolved Apr 08, 2026, 04:11 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 30, 2026, 12:43 PM UTC· resolved Mar 30, 2026, 12:43 PM UTC

1. resolved Mar 30, 2026, 12:43 PM UTC

   We have identified the cause of this issue and have produced a fix in Octopus version 2026.2.3825. Please email [email protected] if you are seeing AWS region endpoint errors in your deployments similar to the one in the title and we can discuss upgrade options.

Read the full incident report →

Started Mar 24, 2026, 04:13 AM UTC· resolved Mar 25, 2026, 06:09 AM UTC

1. investigating Mar 24, 2026, 04:13 AM UTC

   We have identified the cause and are working to complete it as quickly as possible. We will provide another update once the issue is resolved.

2. identified Mar 24, 2026, 04:13 AM UTC

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

3. monitoring Mar 24, 2026, 05:58 AM UTC

   We have a resolution for the issue, and it should be rolled out to customer instances during their next maintenance windows. If this blocks your deployments in the meantime, please reach out to support.

4. resolved Mar 25, 2026, 06:09 AM UTC

   This incident has been resolved. Please don't hesitate to reach out to our support team if you are still having any related problems.

Read the full incident report →

Started Feb 26, 2026, 01:51 AM UTC· resolved Feb 26, 2026, 05:47 AM UTC

1. identified Feb 26, 2026, 01:51 AM UTC

   Our upstream email provider is currently experiencing issues delivering emails from Octopus. This impacts all emails, including email verification during authentication, Octopus Cloud subscription invitations, and billing notifications. We're currently investigating and will update this page when we know more.

2. identified Feb 26, 2026, 05:11 AM UTC

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

3. identified Feb 26, 2026, 05:32 AM UTC

   Sign-in/sign-up emails have been restored. Note: emails will now be sent from [email protected]

4. resolved Feb 26, 2026, 05:47 AM UTC

   Email services have now been restored. Please contact [email protected] if you encounter any issues with email delivery.

Read the full incident report →

Started Feb 02, 2026, 09:31 PM UTC· resolved Feb 03, 2026, 09:38 PM UTC

1. investigating Feb 02, 2026, 09:31 PM UTC

   Octopus Cloud instances are failing to lease Ubuntu Dynamic Workers due to an issue with our upstream provider. We are currently investigating and working on mitigating the issue.

2. identified Feb 02, 2026, 10:09 PM UTC

   Azure have identified the following issue on their side that affects the Dynamic Workers: Virtual Machines and dependent services - Service management issues in multiple regions. They are actively working to mitigate impact and expect it to be resolved by approximately 00:00 UTC. See Azure status page for additional details: https://azure.status.microsoft/en-gb/status

3. monitoring Feb 02, 2026, 11:46 PM UTC

   Azure have rolled out a fix for this issue and we are seeing Dynamic Workers return to normal operation across all regions.

4. monitoring Feb 02, 2026, 11:49 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Feb 03, 2026, 09:38 PM UTC

   Azure has resolved the issue that was causing our Dynamic Workers lease failures and we haven't seen any additional failures since yesterday.

6. postmortem Feb 13, 2026, 04:58 AM UTC

   # Summary On 2 Feb 2026, between 20:13:34 to 22:56:04 UTC, Octopus Cloud customers in `West US 2` and `West Europe` may have experienced failed deployments or failed runbook runs due to `Ubuntu Dynamic Worker` steps failing on Leasing timeout. This disruption was caused by Azure failing to provision Virtual Machines across multiple regions - see Azure Issue `FNJ8-VQZ` on [Azure Status History](https://azure.status.microsoft/en-us/status/history/). # Background Octopus Cloud [Dynamic Workers](https://octopus.com/docs/octopus-cloud/dynamic-worker) are isolated virtual machines that we provide as part of our Octopus Cloud Subscription offering as a way to execute deployment and runbook steps and scripts, without needing to run on the Octopus Server or deployment targets themselves. Customers can use both Windows and Ubuntu Dynamic Workers. Octopus provides a [dynamic worker pool](https://octopus.com/docs/infrastructure/workers/dynamic-worker-pools) of these virtual machine types from which, as required by your deployment/runbook steps, your Octopus Cloud will exclusively lease a freshly provisioned dynamic worker VM for a limited time. ## Dynamic Workers Lifecycle 1. **Provisioning** - a new Azure Virtual Machine is provisioned, using the requested [Dynamic Worker image](https://octopus.com/docs/infrastructure/workers/dynamic-worker-pools#dynamic-worker-images) \(Windows/Ubuntu with a set of pre-installed tools\). 2. **Pool** - the newly created Dynamic Worker \(VM\) is placed in a worker pool until an instance requests a Dynamic Worker in one of its deployments/runbooks steps. Each region \(US, Europe and Australia\) has different pools for Windows and Ubuntu workers, with additional standby pools that can be turned on in cases of a temporary outage in an Azure region \(see below\). Octopus Cloud continuously monitors the pools’ levels and provision new workers automatically to keep them full. 3. **Leasing** - When a [deployment/runbook that uses a Dynamic Worker](https://octopus.com/docs/infrastructure/workers#where-steps-run) starts, if the instance doesn’t have a leased worker already \(in which case, it will continue using this worker, extending the worker’s lease for the new run\), the Octopus Server will request a new worker from the appropriate pool. This worker will be exclusively leased to this instance until it is no longer needed \(i.e. wasn’t used for an hour\) or until its maximum lifespan is reached \(3 days by default\). 4. **Deletion** - After a worker is no longer needed or it has reached its maximum lifespan, it is considered expired and will be deleted by the system automatically. The next time that the same instance will require a worker, it will lease a new one from the pool \(see above\). ## System Resilience & Safeguards Octopus Cloud implements multiple layers of protection to ensure Dynamic Workers’ availability and minimize customer impact in cases of service disruptions: * **Pre-provisioned Worker Pools:** We maintain multiple [dynamic worker pools](https://octopus.com/docs/infrastructure/workers/dynamic-worker-pools) \(for the different virtual machine OS and sizes\) with ready-to-use workers to provide immediate availability when deployments/runbooks are triggered, rather than waiting for on-demand provisioning. This also provides a safety buffer in cases where we can’t provision new Dynamic Workers due to temporary outages. * **Standby Services in Multiple Regions:** We maintain standby Dynamic Worker services in alternate Azure regions that we activate to provide continuity when a primary region experiences issues # Key Timing ‌ # Timeline and Impact All dates and times below are in UTC **Feb 2 2026:** **18:52:** 1st failed Dynamic Worker provisioning - At this point, our Dynamic Workers Service continued supplying workers successfully from the pools. However, since we couldn’t provision new workers, the pools started depleting. **20:13:** 1st Ubuntu Dynamic Worker lease failed in `West US2` Azure region \(once the pool was depleted\) - start of customer impact **20:47:** Octopus on-call was paged after 3 Dynamic Worker lease requests failed in `West US2`. The on-call then started the incident to investigate the issue **20:47-21:20**: * Octopus engineers started setting up a Dynamic Workers Service on a different Azure region in the US to mitigate the issue. * During the investigation we saw that Dynamic Workers were also failing to provision in the `West Europe` and `East Australia` Azure regions. At this point we realized that this was a multi-region outage in Azure and decided to open a support ticket with them. * Octopus Engineers turned off non-essential services \(e.g. Instance Upgrades\) to preserve the available Dynamic Workers for customer use. **21:24:** an on-call engineer opened a Sev A support ticket with Azure **21:31:** We published the initial partial outage alert for Octopus Cloud on [https://status.octopus.com/](https://status.octopus.com/) **21:33:** 1st Dynamic Worker lease failed in `West Europe` **21:42:** Azure acknowledged the multi-region issue and reported that they are investigating it. **22:56:** We saw the last Dynamic Worker lease failure. After this time, we were able to provision the required Virtual Machines and return the Dynamic Workers successfully to all lease requests. **23:46:** After verifying that all Dynamic Worker pools have been restored and we didn’t see any additional provisioning failures, we updated the incident status to “Mitigated”, and updated the Status page. ‌ **Feb 3 2026:** **6:05:** Azure confirmed that the issue was fully resolved on their side. **21:38:** Incident was resolved and Status page updated ‌ # Technical Details Octopus Cloud uses Azure Virtual Machines in order to supply Dynamic Workers to customers. During this Azure outage, we couldn’t provision new Azure Virtual Machines for our Ubuntu Dynamic Workers. Our pre-provisioned Dynamic Workers’ pools continued supplying Dynamic Workers for additional * 1:21 hours in `West US 2` and * 2:41 hours in `West Europe` before they were depleted and customer requests for new Dynamic Workers started failing. It’s worth noting that `East Australia` customers were not impacted because the pools in this region didn’t deplete during the incident. Additionally, customers that already had a Dynamic Worker leased at the time of the outage were not impacted \(unless their Dynamic Worker expired so a new one was requested during the incident\). ‌ We made preparations to switch to our Dynamic Workers Standby Service on different Azure regions. However, once we realized that this was a multi-region outage, we decided to revert the switch since it wouldn’t have resolved the issue. ‌ Once we saw that we couldn’t supply Dynamic Workers from our standby regions, we turned off non-essential services \(e.g. Instance Upgrades\) to preserve the available Dynamic Workers for customer use. ‌ Once Azure mitigated the issue on their side, our system recovered automatically and resumed providing new Dynamic Workers successfully. ‌ # Remediation Octopus takes service availability seriously. Despite the difficulty with upstream cloud provider outages, especially ones that are widespread across multiple regions, we fully review and remediate any outages that occur. We do this so that we’re continuously improving and maintaining the best possible service we can. Following our post mortem, we identified the following improvements to our system to help identify and mitigate \(where possible\) similar issues earlier: * **Page an on-call earlier -** add an alert to page the on-call when multiple Dynamic Workers in the same region fail to provision. This will allow us to detect similar incidents quicker and give us more time to mitigate the issue, before any Dynamic Worker leases fail and customers are impacted. * **Improve our Dynamic Workers Incident Playbook** to identify multi-regions incidents quicker in order to engage Azure support earlier to resolve the root cause of similar incidents. # Conclusion We apologize to our customers for any disruption and inconvenience as a result of this incident. We have started work on the identified remediations to ensure that we can detect similar incidents more quickly and reduce the impact on our customers as much as possible.

Read the full incident report →

Started Nov 25, 2025, 12:34 PM UTC· resolved Nov 25, 2025, 02:57 PM UTC

1. investigating Nov 25, 2025, 12:34 PM UTC

   We are currently investigating issues with cloud customers accessing their instance via OctopusID. For some customers, this issue seems to be auto resolving after around 5 minutes. Whilst we are investigating the root cause, we recommend attempting to sign in whenever convenient incase you are able to access the instance.

2. investigating Nov 25, 2025, 12:58 PM UTC

   We are currently investigating issues with cloud customers accessing their instance via OctopusID. For some customers, this issue seems to be auto resolving after around 5 minutes. Whilst we are investigating the root cause, we recommend attempting to sign in whenever convenient incase you are able to access the instance.

3. monitoring Nov 25, 2025, 02:00 PM UTC

   We have performed some changes that based on customer feedback, has mitigated this issue. We are still monitoring to ensure this issue does not reoccur, but customers should be able to sign in via OctopusID again.

4. monitoring Nov 25, 2025, 02:56 PM UTC

   After monitoring the platform following our earlier mitigation, we can confirm that the issue has not resurfaced. OctopusID sign-in is functioning normally, and the incident has been resolved.

5. resolved Nov 25, 2025, 02:57 PM UTC

   Resolved.

6. postmortem Dec 08, 2025, 09:27 PM UTC

   # Intermittent sign-in issues for Octopus Cloud instances ## Summary Between November 25, at 10:24 pm AEST, and November 26, at 12:58 am AEST, customers experienced sporadic issues signing into Octopus Cloud instances. These issues stemmed from a database connection leak, which caused some sign-in requests to time out. We apologize for the inconvenience this has caused our customers and are taking steps to prevent it from happening again. ### Timings Time to detection: 9hrs 41mins Time to incident declaration: 9hrs 41mins Time to resolution: 12hrs 15mins ## What happened? \(All dates and times below are in AEST\) ### November 25 **12:43 pm** We deployed a change to our authorization service. This change introduced a bug resulting in database connection leaks. The connection leak only became apparent in high-traffic scenarios, which our current test suite doesn't replicate. As a result, our test suite didn't detect the issue. **10:24 pm** A DevOps Support Engineer declared an incident after receiving reports from customers that they were having difficulty signing into Octopus Cloud instances. **10:24 pm - 11:41 pm** Investigations showed that the issue was due to database connection timeouts. **11:42 pm** Temporary mitigations implemented, including restarting services to release database connections. **11:42 pm - 11:59 pm** Effects of mitigations observed and deemed successful. Incident marked as mitigated. ### November 26 **12:00 am - 12:57 am** Incident responders continue to watch systems. **12:58 am** Mitigation steps considered successful, and the incident marked as resolved. **6:55 am** Root cause of database connection timeouts identified as a connection leak. **6:55 am - 8:33 am** Permanent fix implemented and deployed. ## Remediation and next steps We deployed a new service version to remove the database connection leak. We have also conducted an incident review to identify process improvements to prevent this from occurring in the future. We continue to work towards improving the reliability and security of our authentication and authorization services.

Read the full incident report →

Started Nov 18, 2025, 09:11 PM UTC· resolved Nov 19, 2025, 12:47 AM UTC

1. identified Nov 18, 2025, 09:11 PM UTC

   GitHub is experiencing issue with git operations, resulting in in-product git operations to be degraded or fail. We're continuing to monitor this upstream outage.

2. monitoring Nov 18, 2025, 10:01 PM UTC

   GitHub reports that git operations have been restored. We will continue to monitor this situation.

3. resolved Nov 19, 2025, 12:47 AM UTC

   We have observed no further errors stemming from this issue.

Read the full incident report →

Started Oct 29, 2025, 04:31 PM UTC· resolved Oct 30, 2025, 01:13 AM UTC

1. investigating Oct 29, 2025, 04:31 PM UTC

   We are currently investigating the issue.

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

   It appears this outage is due to a DNS issue with our upstream provider. We are currently awaiting for mitigation from the upstream provider to restore Octopus.com and related services.

3. identified Oct 29, 2025, 07:00 PM UTC

   Customers may notice intermittent access to Octopus.com and Octopus services. Our upstream provider has made progress to mitigate the issue. We will continue to monitor the situation. We have contingency plans we are prepared to deploy if service recovery progress from the upstream provider mitigation stalls.

4. identified Oct 29, 2025, 09:13 PM UTC

   As we continue to monitor Octopus.com and Octopus services, metrics are showing services becoming more reliably available. Our upstream provider is currently estimating full or near full mitigation approximately 2 hours from now (approximately 23:20 UTC on 29 October 2025). We will provide additional updates as the situation necessitates.

5. identified Oct 29, 2025, 11:57 PM UTC

   As we continue to monitor Octopus.com and Octopus services, metrics are showing services becoming more reliably available. We are still waiting for our upstream provider's resolution and expect to give another update approximately 1 hour from now (approximately 00:55 UTC on 30 October 2025). We will continue to provide additional updates as the situation necessitates.

6. resolved Oct 30, 2025, 01:13 AM UTC

   All Octopus services affected by this outage are now operational.

Read the full incident report →

Started Oct 20, 2025, 07:34 AM UTC· resolved Oct 21, 2025, 01:11 AM UTC

1. identified Oct 20, 2025, 07:34 AM UTC

   Docker Hub experienced issues that prevented access to container images, resulting in deployment failures for projects relying on those images.

2. monitoring Oct 20, 2025, 12:44 PM UTC

   Docker Hub experienced issues that prevented access to container images, resulting in deployment failures for projects relying on those images.

3. monitoring Oct 20, 2025, 12:48 PM UTC

   Most of the Docker Hub services seem to be operational but the incident is still on-going.

4. monitoring Oct 21, 2025, 12:15 AM UTC

   Most of the Docker Hub services seem to be operational and we are continuing to monitor the situation

5. resolved Oct 21, 2025, 01:11 AM UTC

   Docker Hub have resolved their incident and we have not observed any further issues

Read the full incident report →

Started Oct 12, 2025, 11:43 PM UTC· resolved Oct 13, 2025, 12:24 AM UTC

1. identified Oct 12, 2025, 11:43 PM UTC

   We have identified an issue where Kubernetes deployments using the Kubernetes agent may fail due to a failure to pull the octopusdeploy/kubernetes-agent-tools-base docker image.

2. monitoring Oct 12, 2025, 11:45 PM UTC

   We have fixed the issue and pushed the missing tags to DockerHub. Kubernetes agent deployments should be working again.

3. resolved Oct 13, 2025, 12:24 AM UTC

   This has been resolved. All missing tags have been published to DockerHub and we are seeing successful deployments using these new tags.

Read the full incident report →

Started Sep 25, 2025, 01:06 AM UTC· resolved Sep 25, 2025, 04:18 AM UTC

1. identified Sep 25, 2025, 01:06 AM UTC

   Docker Hub is experiencing an active incident: https://www.dockerstatus.com/pages/incident/533c6539221ae15e3f000031/68d47a2f93c09e05486d93a9 Octopus customers may experience issues pulling images from Docker Hub, including: 1. Octopus Server self-host images 2. Deployment process container images including execution containers and reference packages hosted by Docker Workarounds are available, please contact [email protected].

2. monitoring Sep 25, 2025, 01:23 AM UTC

   Docker has implemented a fix and we are monitoring.

3. resolved Sep 25, 2025, 04:18 AM UTC

   The Docker Hub incident is resolved and we have not observed any ongoing issues.

4. postmortem Oct 09, 2025, 03:37 AM UTC

   # **Incident Summary** Docker Hub experienced authentication issues that prevented access to container images, resulting in deployment failures for projects relying on those images. ## **What We're Doing** Following this incident, we've identified several improvements to enhance service resilience and customer communication: ### **Visibility & Monitoring** * Communicate third-party service outages more clearly on our status page * Explore in-app messaging to alert customers during service disruptions ### **Resilience & Good Practices** * Review image retrieval reliability and address identified risks * Share good practices with customers to help reduce impacts when Docker Hub is unavailable

Read the full incident report →

Started Sep 15, 2025, 03:11 AM UTC· resolved Sep 15, 2025, 06:05 AM UTC

1. investigating Sep 15, 2025, 03:11 AM UTC

   We are investigating reports of intermittent Azure authentication issues during deployments and runbook runs. We are working with Microsoft to resolve this issue.

2. monitoring Sep 15, 2025, 05:57 AM UTC

   The downstream issue with running `az login` commands in Azure steps appears to be working again. We will be continuing to monitor this.

3. resolved Sep 15, 2025, 06:05 AM UTC

   The downstream issue with Azure CLI login commands has been resolved by Azure.

Read the full incident report →

Started Sep 04, 2025, 02:31 AM UTC· resolved Sep 05, 2025, 03:50 AM UTC

1. monitoring Sep 04, 2025, 02:31 AM UTC

   Symptom: The Deployment or Runbook appears to have started but has not produced any logs after an extended period of time. Mitigation: Manually cancel the Deployment or Runbook, then re-run the task. Please note that cancellation may take approximately 10 minutes. After the next maintenance window all affected tasks will be automatically cancelled. Please reach out to https://octopus.com/support if you would like tasks to be automatically cancelled earlier.

2. resolved Sep 05, 2025, 03:50 AM UTC

   This issue is resolved, please reach out to https://octopus.com/support if you are still experiencing deployments that fail to start.

Read the full incident report →

Started May 22, 2025, 11:35 PM UTC· resolved May 23, 2025, 03:34 AM UTC

1. investigating May 22, 2025, 11:35 PM UTC

   octopus.com/downloads top navigation bar is failing to load correctly. We are investigating the cause. Links to downloads from this website are still correct. Please reload the page if you cannot see the content.

2. identified May 23, 2025, 01:40 AM UTC

   We have identified the issue with the top navigation bar loading and are working on a fix.

3. monitoring May 23, 2025, 03:27 AM UTC

   We have shipped a change to fix the navigation bar issue and are monitoring to ensure it works in all regions.

4. resolved May 23, 2025, 03:34 AM UTC

   We have fixed the issue with the navigation bar on octopus.com/downloads

Read the full incident report →

Started Mar 28, 2025, 11:54 AM UTC· resolved Mar 28, 2025, 01:10 PM UTC

1. identified Mar 28, 2025, 11:54 AM UTC

   We are aware of an issue where a recent update has caused ECS Update steps to fail deployment.

2. monitoring Mar 28, 2025, 12:02 PM UTC

   We have uploaded a new version of the ECS Update step. Affected customers can manually force a re-acquisition of the updated packages via the following steps 1. Go to Tasks 2. Click Show Advanced filters 3. Check "Include System Tasks" 4. Select the "Acquire new steps and targets" from the Task Type 5. Choose the most previously run task 6. Select "Re-run" from the context menu (3 dots).

3. resolved Mar 28, 2025, 01:10 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 05, 2025, 02:17 PM UTC· resolved Mar 05, 2025, 10:23 PM UTC

1. investigating Mar 05, 2025, 02:17 PM UTC

   Octopus Deploy is aware of performance issues for some customers on Octopus Cloud. Our engineers are investigating and we will provide an update soon.

2. investigating Mar 05, 2025, 04:17 PM UTC

   We continue to see issues with our upstream to instances within the WestEU region. We are awaiting further information from Azure.

3. resolved Mar 05, 2025, 10:23 PM UTC

   Azure have advised us this issue has been mitigated. Octopus Cloud instances in the West Europe region were affected on 5 March from 6 AM to 5 PM UTC. Azure will be providing us with a Root Cause Analysis, after which we can share more information.

Read the full incident report →

Started Feb 12, 2025, 01:47 PM UTC· resolved Feb 12, 2025, 09:36 PM UTC

1. investigating Feb 12, 2025, 01:47 PM UTC

   We're investigating an issue with the v5 and below versions of the step 'Use Octopus CLI Tool' on build servers where customers are seeing the error 'unable to verify the first certificate'. This is currently affecting customer deployments due to not being able to install the depreciated version of the OctoCLI. The v6 versions of our ADO extension tasks do not require the OctoCLI so upgrading to our v6 steps will resolve this issue. Find out more information about the migration to the new step version here: https://octopus.com/blog/azure-devops-octopus-v6

2. monitoring Feb 12, 2025, 04:32 PM UTC

   We have updated the certificate chain on our host, which has resolved the verification issues. We are continuing to monitor the outcome of this change.

3. resolved Feb 12, 2025, 09:36 PM UTC

   We've had no further reports of this issue following the certificate update, and customers have indicated that they are back up and deploying. If you encounter any further issues, please email [email protected]

Read the full incident report →