Last checked
Cloud infrastructure and digital transformation solutions for businesses.
Experiencing an issue?
Ionos Cloud宕机了吗?
Degraded performance
Share your experience to help others stay informed.
Service status and report activity over the last 24 hours, in 15-minute intervals. Early warnings and official incidents are shown separately.
Loading reports… · Last 24 hours
Tap a bar to keep its details open. With the chart focused, use Left and Right to move between intervals, Home or End to jump, and Escape to close. Full data is available in the table below.
| Start | End | Reports | Status |
|---|
Official status checked
Ionos Cloud is experiencing issues
Official provider statusOfficial incident active
Cloud Support: Limited Phone Support Availability — While phone support will generally be available, our Support capacity is reduced due to multiple cases of sick leave. We want to inform you that our phone support will be limited during the following time slots, leading to increased response times on the phone channel. In these cases, please reach out per email. Thank you.
Official provider statusOfficial incident resolved
Object Storage - Increased latency in eu-central-1 — # Root Cause Analysis ## What happened? Starting approximately 19:00 UTC on 24 August 2026, customers accessing S3 Object Storage in the Frankfurt \(FRA4\) data center experienced elevated latency across all operations - uploads, downloads, metadata requests, and deletions. Intermittent HTTP 503 Service Unavailable and 404 Not Found errors were observed on object read requests. The impact was measurable for all customer which had buckets in the both affected datacenters of the region, with some customers experiencing severe degradation depending on their bucket configuration and access patterns. The incident remained in progress with high priority from 25 August through 3 September 2026. The latency issue was mitigated at approximately 13:40 UTC on 3 September 2026. ## How was this possible? \(Root Cause\) **Primary cause - Software bug in Quality of Service \(QoS\) subsystem** IONOS S3 Object Storage in the Frankfurt region is using a distributed object storage system. A QoS feature of this service - implemented via a redis-qos service - applies rate limiting to S3 requests at the cluster level. A bug in the S3 service leads to not well distributed queries to the Redis-QOS service \(which is served by multiple server for high availability\) this caused the Redis-QOS process to reach and sustain 100% CPU utilization, progressively slowing down all S3 request processing at the cluster level. This affected every request passing through the affected nodes, irrespective of the operation type or the specific bucket accessed. This is an internal defect within the software used. The bug caused the S3 service to consume all available resources before load reached request levels that would normally trigger throttling, meaning the degradation occurred continuously rather than only under peak conditions. In close cooperation with the software vendor, we disabled the QoS rate-limiting function on 3 September, which fully resolved the latency issue. S3 is currently operating without some QoS features while a permanent fix is prepared by the vendor. ## What are we doing to prevent recurrence? **Already completed:** * QoS disabled in the S3 service - fully resolved the latency issue. \(DONE\) * Requesting permanent solution from the software vendor. \(INPROGRESS\) **Short-term - ETA: within 2 weeks:** * Permanent fix for the Cloudian QoS bug: IONOS Cloud is in active coordination with the vendor to obtain and deploy a fix for the redis-qos defect. Once the fix is validated, lost QoS features will be re-enabled. * Database partition monitoring: We are implementing monitoring that alerts on partition size growth before any individual partition approaches a problematic threshold. This will allow our team to identify and address bucket layout issues proactively. **Mid-term - ETA: 1 to 3 months:** * QoS architecture review: Following the permanent QoS fix, we will review the architectural isolation of the QoS service together with the vendor to ensure that a future resource contention event in the rate-limiting layer cannot propagate to the request path at the same scale. * Monitoring and alerting improvements: We are extending cluster-level monitoring to surface redis-qos CPU saturation and database compaction backlog as first-class incident signals, with automated escalation before customer-visible latency develops. ## Closing remarks An incident of this duration in a core infrastructure service is not acceptable. The high-latency period persisted for nine days, during which customer workloads depending on S3 in the Frankfurt region were degraded. Multiple optimisations and mitigation strategies were implemented during the course of the incident, but could only improve the situation for individual buckets and only to a certain extent. Detecting the underlying QoS bug and developing a mitigation required coordination with the vendor’s engineering team. While the latency issue is mitigated, we remain in close contact with the vendor. The engineering work to deliver a permanent QoS fix, reduce database partition pressure, and prevent recurrence is in progress. We are also working closely with our technology partner to understand delays in the analysis of the root cause of this incident. We will conduct a joint post mortem to identify areas where collaboration during incidents can be improved. We recognise the impact this incident caused to your operations. We believe that the listed measures will help us prevent similar error patterns and speed up analysis and recovery for software related issues in the future. We thank you for your patience during the incident.
Official provider statusOfficial incident resolved
Cloud Support: Limited Phone Support Availability — We managed to fully re-establish our service, Support is back. thank you for your patience.
Official provider status0 outage reports in the last 24 hours.
Official status observations, not measured service uptime.
Official incidents, early warnings and community reports are identified separately. Early warning history covers only the last 24 hours. Dates use your time zone.
| Incident name | Duration | StartedUTC | Acknowledged | Severity |
|---|---|---|---|---|
| 8h 48mOngoing | Yes | Minor | ||
| 85h 38m | Yes | Minor | ||
| 2h 37m | Yes | Minor | ||
| 1h 28m | Yes | Major | ||
| 195h 45m | Yes | Minor | ||
| 5h | Yes | Minor | ||
| 57h 57m | Yes | Minor | ||
| 137h 28m | Yes | Minor |
Planned work published by the official provider.
Overview Following the successful automated migration of all DBaaS PostgreSQL clusters to our v2 infrastructure earlier this month, IONOS Cloud is proceeding with the final decommissioning of the legacy PostgreSQL API v1. The API v1 endpoints will be permanently disabled. Once disabled, any programmatic requests made to the v1 API will be rejected. Impact & Required Actions Because your underlying clusters have already been migrated, your databases will experience zero downtime during this API shutdown. However, you must ensure your management tools are updated to avoid disruption to your deployment workflows: - Endpoint Update: Ensure all scripts, Terraform configurations, and SDKs are pointing exclusively to the regional API v2 endpoints. - Authentication Switch: PostgreSQL API v2 does not support BASIC authentication. If you have not done so already, you must immediately switch your API and SDK authentication to TOKEN authentication. API v2 Benefits Reminder Migrating your tooling to API v2 grants you access to the new platform features: - Regional Endpoints: Lower-latency API access routed directly to your specific region. - Observability Integration: Access to forward cluster logs and metrics directly to IONOS Logging and Monitoring. - SSD Premium Infrastructure: Full management capabilities for the upgraded, high-performance SSD Premium storage tier. Affected services: Database as a Service (DBaaS) Location: Global Services
Started 2026年9月28日 UTC 14:00 · Ongoing
分享您对 Ionos Cloud 的看法
成为第一个评论的人!
Uptimus 通过官方状态源监控 Ionos Cloud,并将事件、维护和组件健康状况统一为一致的服务状态。
此页面目前包含 132 个受监控组件、72 个事件、68 个维护窗口和 48 天已知历史。
Uptimus 是独立监控服务,与 Ionos Cloud 无关联。健康状态并不保证每位用户、设备或地区都未受影响。
当 Ionos Cloud 或受监控组件报告重大或关键中断时接收通知。 提醒可通过工作区启用的渠道发送,包括电子邮件、推送和已配置的集成。 可用历史包含 72 个事件,为提醒提供当前状态之外的背景。 最近收录的事件是“Cloud Support: Limited Phone Support Availability”。
接收有关性能下降、部分影响和非完全中断的小型事件通知。 Uptimus 当前跟踪 Ionos Cloud 的 132 个组件: Backup Service, Cloud Support, Compute, Compute。 提醒可通过工作区启用的渠道发送,包括电子邮件、推送和已配置的集成。
Downdetector 公共页面主要基于用户报告。Uptimus 还会在来源提供时结合官方事件、维护窗口和组件状态。
| 比较标准 | Uptimus | Downdetector |
|---|---|---|
| Ionos Cloud 的社区中断报告 | 已包含 |
The official status page for Ionos Cloud reports degraded performance. An unresolved official incident is listed: “Cloud Support: Limited Phone Support Availability”. Components reported as affected: Cloud Support. 0 reports were recorded for Ionos Cloud in the last 24 hours. Last official check: .
The scheduled maintenance has been completed.
Started 2026年8月31日 UTC 14:00 · Resolved 2026年8月31日 UTC 16:00
The scheduled maintenance has been completed.
Started 2026年8月31日 UTC 14:00 · Resolved 2026年8月31日 UTC 16:00
The scheduled maintenance has been completed.
Started 2026年8月27日 UTC 14:00 · Resolved 2026年8月27日 UTC 17:00
The scheduled maintenance has been completed.
Started 2026年8月26日 UTC 14:00 · Resolved 2026年8月26日 UTC 17:00
The scheduled maintenance has been completed.
Started 2026年8月24日 UTC 15:00 · Resolved 2026年8月24日 UTC 17:00
The scheduled maintenance has been completed.
Started 2026年8月24日 UTC 14:00 · Resolved 2026年8月28日 UTC 06:00
The scheduled maintenance has been completed.
Started 2026年8月20日 UTC 14:00 · Resolved 2026年8月20日 UTC 17:00
| 已包含 |
| 区分个别报告和大范围中断的自适应基线 | 已包含 | 已包含 |
|---|
| 24 小时报表活动和区域中断视图 | 已包含 | 已包含 |
|---|
| 在一个工作区管理网站、状态提供商、Steam 游戏及 Android 应用和游戏 | 已包含 | 独立产品 |
|---|
| 从同一工作区发送邮件、推送和 Webhook 告警 | 已包含 | 独立产品 |
|---|
| Ionos Cloud 的官方事件更新和状态时间线 | 已包含 | 以用户报告为主 |
|---|
| 分别展示组件健康与维护窗口 | 已包含 | 公共页面功能有限 |
|---|
Rate this service
No reviews yet