Hetzner Object Storage Degraded for Over a Month: Why Are Users Unaware?

Event Overview

A recent post on Hacker News with only 10 points and zero comments is titled "Hetzner Object Storage Degraded for Over a Month." The post includes no technical details or evidence, but the title itself raises a question worth asking: why would a European cloud provider known for stability let its object storage remain in a degraded state for so long?

Hetzner has long enjoyed a reputation as the "king of value" in developer communities, and its Object Storage service is often used for backups, static asset hosting, and small-to-medium data lake scenarios. For this reason, even an allegation of prolonged degradation without details strikes a nerve among users who rely on the service for architecture design.

What a Month-Long Degradation Could Mean

In the cloud service context, "degraded" usually means the service is available but its performance or consistency is below promised levels—perhaps elevated request latency, slower writes in some regions, or a non-zero error rate that has not triggered a full outage.

If this state persists for more than a month, it has crossed the monthly measurement period defined by most SLAs. For users, this "boiling frog" degradation is harder to notice than a brief full outage: monitoring dashboards are not red, alerts are not triggered, but backup jobs quietly take longer to complete, and cold data reads occasionally time out.

SLA and Monthly Measurement Periods: An SLA (Service Level Agreement) is a cloud provider's commitment to metrics such as availability and latency, usually measured over a monthly or annual window. For example, "99.9% monthly availability" means about 43 minutes of unavailability per month is allowed. If a degraded state lasts more than a month, it crosses the SLA measurement boundary, and users may be unable to obtain breach compensation within a single monthly cycle. It also means the provider may exclude "degraded" from availability calculations, so SLA compensation is not triggered. This explains why prolonged degradation is relatively low-cost for the provider but can have cumulative effects on users.

Why Users May Be Completely Unaware

The zero-comment status of the post is itself a signal. On one hand, low-scoring posts on Hacker News easily sink, which does not necessarily mean the problem does not exist; on the other hand, object storage usage patterns naturally mask degradation:

• Backup and archival workloads are insensitive to latency, so slower performance does not immediately surface;
• Most users do not set up separate fine-grained SLO monitoring for object storage;
• Provider public status pages often summarize issues as "partial performance degradation" without providing historical trends.

Together, these three factors make it entirely possible for a month-long degradation to go unnoticed on the user side.

S3 Compatibility and Migration Costs for Object Storage: S3 compatibility means a service provides an API similar to Amazon S3, allowing users to access it with existing S3 SDKs, tools, and ecosystem components (such as rclone and MinIO clients). This compatibility lowers migration costs for multi-cloud or hybrid-cloud architectures, but it does not mean migration is free. Data egress fees, network latency, differences in authentication mechanisms, and different consistency models can all become hidden obstacles. Therefore, although S3 compatibility provides a technical foundation for multi-backend strategies, actual execution still requires evaluating data volume, access patterns, and cost structure.

What This Means for Architectures That Rely on Hetzner

For projects that use Hetzner Object Storage as their only storage backend, this event offers concrete lessons:

A status page is not the whole of monitoring. The update frequency and granularity of provider status pages are beyond your control. Users need to instrument their own critical paths and at least record the PUT/GET latency distribution for object storage.

Degradation also needs an SLO. Most teams only alert on "complete unavailability" and ignore chronic issues such as doubled latency. Setting a P95 latency baseline for object storage is what turns "degraded for a month" into "detected within an hour."

Multiple backends are not over-engineering. The S3 compatibility of object storage makes migration costs relatively controllable. Keeping a cold backup channel for critical data is a low-cost insurance policy against prolonged degradation.

P95 Latency Baseline: P95 latency refers to the value below which 95% of request response times fall, and it is a common metric for measuring tail latency in service performance. Compared with average latency, P95 better reflects "long tail" user experience problems. Establishing a P95 latency baseline for object storage means continuously recording and analyzing the latency distribution of PUT/GET operations and triggering alerts when the P95 value deviates significantly from the historical baseline. This helps teams detect problems in the early stages of degradation (for example, when latency doubles but there is no complete outage), rather than waiting for user complaints or backup failures. The baseline needs to be adjusted dynamically based on business hours, data size, and concurrency to avoid false alarms.

The Information Vacuum Is Itself a Problem

The greatest value of this post is not what it proves, but what it exposes: when an allegation of prolonged degradation appears, the community has no ability to cross-verify it. There is no status page screenshot, no link to a provider announcement, and no reproduction description from affected users.

For cloud providers, if a prolonged degradation lacks transparent process communication, the damage is to trust, not just to availability numbers. For users, making architecture decisions in an information vacuum is itself a risk exposure.

Editorial Note

It should be noted that this material consists only of a title and interaction data, and lacks any cross-verifiable information such as provider announcements, user reproductions, or third-party monitoring. The above analysis is based on the statement that "the degradation lasted for a month" and is an inference about cloud storage operations practices, not a confirmation of Hetzner's service status. Readers concerned about their own instances should rely on the official status page and their own monitoring data.