Contabo Shut Down My Server Without Warning and I Found Out Five Hours Later by Accident

The server had been running without incident for months. Contabo, the German hosting company known for extremely affordable VPS plans, was handling everything from web applications to scheduled jobs to database operations. There were no unusual spikes in traffic, no signs of hardware degradation, no warning emails from anyone. The server was simply there, doing what servers do, until it was not. Somewhere around mid-morning, the machine went dark. No notification arrived. No incident report was published. No automated system flagged the problem. The applications that depended on that server continued to fail silently, returning connection errors to whoever happened to visit, while the hours ticked forward without anyone being aware that anything was wrong.

Five hours passed before the problem was discovered, and the discovery itself was entirely accidental. A routine attempt to SSH into the server for an unrelated maintenance task returned a connection timeout. That was the moment the reality set in. Five full hours of downtime. Every web property hosted on that machine had been unreachable. Every API endpoint had returned errors. Every scheduled task had failed to execute. And nobody knew because there was nothing in place to sound the alarm. The assumption had been that the hosting provider would at least send an email if something went wrong on their end, or that surely someone would notice if a website went offline. Both assumptions turned out to be dangerously wrong.

The aftermath was a long afternoon of damage assessment. Checking logs to determine exactly when the outage started. Reviewing which services had been affected. Calculating how many API requests had failed during those five hours. Reaching out to Contabo support to learn that the server had been stopped due to what they described as a routine maintenance event, one that apparently did not warrant advance notification to the customer. The frustration was not just about the downtime itself. Downtime happens. Hardware fails. Networks experience issues. The frustration was about the total absence of information, the complete silence between the moment the server went offline and the moment the problem was stumbled upon by chance.

Why Passive Monitoring Fails When You Need It Most

Before that incident, the monitoring strategy could be described generously as passive and realistically as nonexistent. The approach was simple: if something breaks, someone will notice. Users will complain. Error rates in third-party analytics will spike. The hosting provider will communicate. Surely, in the modern age of cloud infrastructure and automated systems, a server going completely offline would trigger some kind of observable reaction. But none of those things happened within any useful timeframe. Users who encountered errors simply left. Analytics platforms only report what they can measure, and when the server that feeds them data goes offline, there is nothing to measure. The hosting provider, as it turned out, did not consider an unannounced shutdown to be something worth emailing about.

This is the trap that catches a surprising number of small to mid-size operations. Enterprise companies run dedicated monitoring stacks with entire teams overseeing dashboards around the clock. Individual developers and small businesses tend to operate on the assumption that their hosting is reliable enough, that catastrophic failures are rare enough, and that the manual overhead of setting up monitoring is not worth the effort for something that "probably won't happen." The problem with that logic is that the cost of downtime scales with how long it goes undetected, not with how often it occurs. A five-minute outage that gets caught immediately is a minor event. A five-hour outage that nobody notices until stumbling upon it by accident is a genuine business problem.

The incident also exposed a subtler issue with relying on the hosting provider as the single source of truth about server health. Contabo, like most budget hosting companies, provides basic server status information through a control panel. But visiting the control panel requires already suspecting that something is wrong. There is no push mechanism, no proactive alerting, no system that reaches out and says "your server is offline, here is what happened." The relationship is entirely reactive. The customer must ask the question before the answer is provided. In a world where every second of downtime translates to missed revenue, lost trust, and damaged search engine rankings, that reactive model is fundamentally inadequate.

What Five Hours of Silence Actually Costs

Quantifying the damage from an undetected outage is more complicated than simply counting the minutes. The immediate costs are straightforward enough: lost API revenue, failed webhook deliveries, broken integrations for users who depend on uptime for their own workflows. But the secondary costs accumulate in ways that do not show up on any dashboard. Search engine crawlers that arrive during an outage and receive error responses can trigger ranking penalties that take weeks to recover from. Users who encounter a dead site may never return, and there is no way to know how many potential customers visited during those five hours, received an error page, and formed a permanent negative impression.

SSL certificate expiration is another silent threat that compounds the problem. A certificate that expires without warning does not just create a security vulnerability. It triggers browser warnings that actively discourage visitors from proceeding to the site. Search engines treat expired certificates as a ranking signal. And unlike a server outage, which at least resolves once the server comes back online, an expired certificate continues causing damage until someone manually renews it. The combination of unmonitored server health and unmonitored certificate validity creates a situation where multiple failure modes can stack on top of each other, each one making the recovery more difficult.

Response time degradation is yet another dimension that passive monitoring completely misses. A server does not always go from working to dead in a single moment. More often, performance degrades gradually. Response times that were 200 milliseconds start creeping up to 800, then 1500, then 3000. By the time the server actually crashes, the user experience has been deteriorating for hours or days. Without active monitoring that tracks response times and alerts when thresholds are exceeded, that gradual degradation goes entirely unnoticed until the final, catastrophic failure. And by then, the damage to user experience and search rankings has already been done.

Building the Monitor That Should Have Existed

The decision to build uptime.yeb.to was not a spontaneous reaction to a bad day. It was the logical conclusion of a problem that had been building for a long time and finally became impossible to ignore. The requirements were clear from the start because they came directly from lived experience. The monitor needed to check server availability continuously, not once per hour or once per day, but frequently enough that an outage would be detected within seconds. It needed to verify not just that the server was responding to ping requests, but that HTTPS connections were completing successfully, that SSL certificates were valid and not approaching expiration, and that response times were within acceptable ranges. And it needed to deliver alerts immediately, not through a dashboard that required manual checking, but through email notifications that would arrive in the inbox within seconds of a problem being detected.

The architecture that emerged reflects those priorities. Every monitored endpoint gets checked at regular intervals across multiple dimensions simultaneously. A ping check confirms basic network reachability. An HTTPS check verifies that the web server is responding and that the SSL handshake completes without errors. A certificate check examines the expiration date and alerts when renewal is needed. A response time check measures how long the full request takes and flags degradation before it becomes critical. Each of these checks produces a data point that feeds into both real-time alerting and historical trend analysis, which means the system does not just catch outages after they happen but also reveals patterns that can predict problems before they occur.

Daily and weekly digest emails provide a summary view of all monitored endpoints, their uptime percentages, average response times, and any incidents that occurred during the period. These digests serve a different purpose than the real-time alerts. While alerts are about catching problems in the moment, digests are about understanding the overall health trajectory of an infrastructure. A server that maintained 99.9% uptime but showed steadily increasing response times over the past two weeks is a server heading toward trouble, and the digest makes that trend visible in a way that individual alert emails cannot.

From Personal Tool to Platform

What started as a solution to a personal crisis gradually expanded into something more broadly useful. The multi-region monitoring capability, which sends checks from six different geographic locations, came from a real scenario where a server was accessible from Europe but unreachable from North America due to a routing issue. Single-location monitoring would have reported everything as fine. Multi-region probes caught the discrepancy immediately and identified exactly which geographic regions were affected. This kind of insight is invaluable for anyone serving a global audience, where a regional outage can go completely undetected if monitoring only happens from one location.

The incident history feature grew from the need to have hard data during conversations with hosting providers. When contacting support about recurring issues, having a detailed timeline of every outage, its duration, the specific checks that failed, and the response time measurements before and after the incident transforms the conversation from "we think there was some downtime" into "here are the exact timestamps, durations, and failure patterns." That data makes it significantly easier to hold providers accountable and to make informed decisions about whether to stay with a hosting company or migrate elsewhere.

The entire platform at uptime.yeb.to now exists because of one unannounced server shutdown and five hours of silence. Every feature traces back to a specific failure that would have been caught, or prevented entirely, by proper monitoring. The Contabo incident was not the last server problem that occurred, but it was the last one that went unnoticed for five hours. That distinction makes all the difference.