Update - We are continuing to investigate this issue.
Jul 19, 2026 - 13:36 UTC
Update - We are continuing to investigate this issue.
Jul 19, 2026 - 13:34 UTC
Investigating - Our Engineering team is investigating an issue with attaching volume to the droplets in the NYC1, NYC3, SGP1, SYD1 and BLR1 regions. During this time you may experience an issue with attaching volume to the Droplet(s). We apologize for the inconvenience and will share an update once we have more information.
Jul 19, 2026 - 09:51 UTC
Resolved -
Our engineering team has resolved the outbound network connectivity issue in the BLR1 region. If you continue to experience problems, please open a ticket with our support team. We apologize for any inconvenience.
Jul 19, 09:52 UTC
Monitoring -
Our engineering team has implemented the necessary fixes affecting upstream network connectivity for Droplet-based services in the BLR1 region. Users should now be able to connect to the external endpoints from Droplets in BLR1.
We are currently monitoring the situation to ensure that the service has returned to normal operation and remain stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
Jul 19, 09:31 UTC
Identified -
Our Engineering team has identified an issue affecting upstream network connectivity for Droplet-based services in the BLR1 region and is actively working with the relevant upstream providers to implement a resolution.
Customers may continue to experience intermittent timeouts or connectivity issues when attempting to reach external endpoints from Droplets in BLR1.
We will provide another update once the issue has been fully resolved or when additional information becomes available.
Jul 19, 08:27 UTC
Investigating -
We are currently investigating an issue affecting outbound network traffic for Droplets in the BLR1 region. Customers may experience timeout errors or connectivity issues when attempting to reach external services. Our Engineering team is actively investigating the issue and working to identify the root cause. We will provide additional updates as soon as more information becomes available.
Jul 19, 06:57 UTC
Resolved -
Our Engineering team has confirmed that the underlying issue affecting Reserved IP routing in the TOR1 region has been fully resolved, and services are now operating normally.
If you continue to experience any issues, please contact our Support team by opening a ticket. We apologize for any inconvenience caused.
Jul 16, 17:24 UTC
Monitoring -
Our Engineering team has implemented a fix for the issue affecting Reserved IP routing in the TOR1 region, and we are currently monitoring the results.
Inbound and outbound traffic to and from Reserved IPs in TOR1 should now be restored. If you reassigned your Reserved IP as a workaround and are still experiencing issues, please reach out to our support team.
We will continue to monitor the situation closely and provide a further update once we have confirmed the issue is fully resolved.
Jul 16, 17:01 UTC
Identified -
Our Engineering team has identified the cause of the issue affecting Reserved IP routing in the TOR1 region, which was causing inbound and outbound traffic to and from Reserved IPs in TOR1 to fail.
Detaching and reassigning the Reserved IP to the Droplet may restore connectivity in the meantime. We recommend trying this workaround if you are still experiencing issues with your Reserved IP in TOR1.
Our engineering team is now working on implementing a fix. We will provide updates as more information becomes available.
Jul 16, 15:30 UTC
Investigating -
Our Engineering team is investigating an issue affecting Reserved IP routing in the TOR1 region. The issue is causing inbound and outbound traffic to and from Reserved IPs in TOR1 to fail.
In the meantime, detaching and reassigning the Reserved IP to the Droplet may restore connectivity. We recommend trying this workaround if you are experiencing issues with your Reserved IP in TOR1.
Our engineering team is actively investigating the root cause and working towards a resolution. We will provide updates as more information becomes available.
Jul 16, 13:39 UTC
Resolved -
The deployed fix has successfully restored full functionality, and our monitoring shows that system performance has completely stabilized. Response times for all Gemma 4 inference workflows have returned to normal baseline levels. We will continue to track platform stability moving forward to ensure long-term reliability. We apologize for any disruption this may have caused to your workflows and appreciate your patience throughout the recovery process.
Jul 15, 21:46 UTC
Monitoring -
A fix has been deployed to resolve the issue. We are closely monitoring system performance to ensure full recovery and normal response times for all Gemma 4 inference workflows.
Jul 15, 10:06 UTC
Identified -
We are currently experiencing an issue affecting customers using the Gemma 4 model on our Serverless Inference platform. Customers may experience significantly increased latency or request timeouts.
Our Engineering team has identified a backend configuration issue as the root cause, which is temporarily impacting model performance. Please be assured that our Engineering team is actively working on a fix and is treating this issue with high priority.
We sincerely apologise for any inconvenience this may have caused and appreciate your patience and understanding. If you have any further questions, please create a support ticket so that we can investigate your specific case further.
Jul 14, 11:07 UTC
Monitoring -
A fix has been deployed to resolve the backend configuration issue. We are closely monitoring system performance to ensure full recovery and normal response times for all Gemma 4 inference workflows.
Jul 13, 22:24 UTC
Identified -
We are currently experiencing an issue where customers using the Gemma 4 model on our Serverless Inference and Dedicated Inference platforms may experience severe latency or request timeouts. Our engineering team has identified a backend configuration issue as the root cause, which is temporarily degrading performance. We are actively working on a fix to restore normal response times and will provide another update as soon as the mitigation is in place
Jul 13, 19:04 UTC
Resolved -
The issue affecting Kubernetes deployments in the NYC1 region has been resolved. Our investigation found intermittent DNS timeouts affecting a small number of DOKS clusters, with affected worker nodes running on shared-CPU Droplets. This is a documented limitation for latency-sensitive cluster DNS workloads such as CoreDNS.
The affected clusters are currently functional. To reduce the risk of recurrence, we recommend running CoreDNS on non-shared/dedicated CPU node pools and using sufficient CoreDNS replicas.
If you continue to see DNS failures or NodeNotReady events, please open a support ticket so we can investigate that cluster specifically.
Jul 11, 01:27 UTC
Monitoring -
The issue affecting Kubernetes deployments in NYC1 has subsided. Workloads should now be functioning normally.
Our Engineering team is continuing to monitor the affected systems to confirm full resolution. We'll update this page if any further action is needed. We apologize for the inconvenience this may have caused.
Jul 10, 01:18 UTC
Investigating -
Our Engineering team is investigating an issue affecting Kubernetes deployments in NYC1. Users may see intermittent DNS failures and NodeNotReady events from application workloads during this time.
We apologize for the inconvenience, we'll share new information on this page as soon as it is available.
Jul 9, 20:31 UTC
Completed -
The scheduled maintenance has been completed.
Jul 7, 15:30 UTC
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jul 7, 10:30 UTC
Scheduled -
Start: 2026-07-07 10:30 UTC End: 2026-07-07 15:30 UTC
During the above maintenance window, our Networking Engineering team will be making changes to the core networking infrastructure on Baremetal GPU to enhance performance and scalability in the NYC2 region.
Expected impact:
We do not expect any customer impact during this maintenance. However, if any unexpected issues arise, our team will continuously monitor the situation and take appropriate corrective actions, including rolling back the change if necessary to restore service stability. We will make every effort to minimize any impact.
Resolved -
Our Engineering team has confirmed that the issue with the Deepseek V4 Pro model in Serverless Inference and Agent Platform has been fully resolved. The model is now operational, and users should be able to use it without experiencing any errors.
If you continue to experience any problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused and appreciate your patience.
Jul 5, 00:53 UTC
Monitoring -
Our Engineering team has implemented a fix for the issue with the Deepseek V4 Pro model in Serverless Inference and Agent Platform. The model should now be operational, and users should no longer receive error 429 messages when attempting to use it. We are currently monitoring the situation to ensure the fix is successful and the model is functioning as expected. We will post an update if any further issues arise. If you continue to experience problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
Jul 4, 23:18 UTC
Investigating -
Our Engineering team is investigating reports of an incident affecting the Deepseek V4 Pro model in Serverless Inference and Agent Platform. Users may experience errors when attempting to use this model, specifically receiving error 429 messages. We apologize for the inconvenience and are working to resolve the issue as soon as possible. We will provide an update once we have more information.
Jul 4, 22:13 UTC