Hetzner Online and AS24940: Why Low-Cost Cloud Still Depends on Expensive Operational Discipline

Summary

RIPE NCC records AS24940 as the active HETZNER-AS autonomous system and identify Hetzner Online GmbH in the registration. A RIPEstat snapshot on 5 August 2026 showed the ASN announced with 94 observed prefix entries. That is strong evidence of a visible network identity, but it is not an uptime certificate or a complete map of Hetzner’s services.
Hetzner describes interconnected data-center parks, DDoS filtering, cloud backups, snapshots and a Cloud Server availability commitment. Its own terms also place important duties on the customer: root and cloud customers administer and secure their systems, backups need deliberate configuration and independent copies, and infrastructure availability does not prove that an application or business process recovered.

Hetzner Online GmbH sells cloud servers, dedicated servers, storage and related infrastructure. Many buyers encounter it through a simple commercial idea: useful computing capacity at a comparatively low price. The operational reality is more complicated. A server is one component in a chain that also includes internet routes, name resolution, identity, firewall rules, data copies, application state, staff access, monitoring and business procedures.

AS24940 is one public identifier in that chain. An autonomous system number, or ASN, is a unique label used by a network when it exchanges routing information with other networks. It is comparable to an organization name on the internet’s road map. The registry can say who is recorded against that label. Routing observers can report which address blocks appeared to be announced by it. Neither record can tell a customer whether an online shop accepted an order, a payroll run completed or a database restored cleanly.

That distinction is the centre of this assessment. Hetzner’s infrastructure can provide a capable and economical foundation. The customer still has to turn the foundation into a reliable service. That means deciding which failures matter, allocating authority, keeping records current, buying or building the necessary redundancy, testing recovery and measuring the result in business terms.

The people affected are not only system administrators. A small retailer may depend on one virtual machine for orders. A software company may run dozens of customer environments. A media team may store irreplaceable assets. A manufacturer may connect remote sites to cloud applications. Finance, legal, customer support and management all carry part of the consequence when an apparently cheap system stops working.

The practical questions are therefore plain. What does the public record establish? Which controls does Hetzner describe? Where does the provider’s authority end? What failures remain possible? Who must notice, decide and act? What would the interruption cost? And what evidence would prove that recovery is complete?

The featured image is a generated, photorealistic editorial scene of a generic technician checking an unbranded network rack. It illustrates the physical work behind network operations. It does not depict Hetzner staff, a Hetzner facility, actual Hetzner equipment, a customer environment, performance, an incident or endorsement.

What the registry says, and what it does not say

The company object used here is the published BTW directory entry for Hetzner Online GmbH. It is a COMPANY entity with no earlier ArticleEntity link at the freshness check. Other directory rows with similar names exist for different record types or regional contexts. They are not substituted for this company identity.

The RIPE NCC RDAP response for AS24940 names the object HETZNER-AS, marks it active and identifies Hetzner Online GmbH in the registrant organization and contact role. RDAP means Registration Data Access Protocol. It is a structured format for retrieving registry records. The captured response reports an original registration event on 3 June 2002 and a last-change event on 30 June 2026.

This is valuable identity evidence. A unique ASN and maintained contacts help other operators understand which organization is recorded for coordination. Abuse reports, routing questions and operational escalation can be directed toward a recognizable role rather than an ambiguous brand name. The record also provides a stable point against which changes can be compared.

The record is not sovereign over the running internet. It does not show every router, fibre path, data centre, cloud region, customer, application or contract. It cannot prove that every recorded contact will answer quickly. It does not establish route authorization for every prefix, physical ownership of every asset, current capacity, latency or service quality.

This boundary matters because people often ask a registry to answer a question that belongs elsewhere. If the question is who is recorded against AS24940, RDAP is an appropriate source. If the question is whether a route was visible this morning, a routing observation is more relevant. If the question is whether a customer application completed a transaction, only operating evidence from that service can answer it.

The responsible control is reconciliation. The legal and administrative ledger, the operator’s internal inventory, route authorization records, observed BGP announcements and support contacts should describe compatible realities. A difference is not automatically wrongdoing. It is a reason to investigate whether the network changed, a record became stale, a customer arrangement applies or an error occurred.

What the routing snapshot adds

RIPEstat provides a time-bounded view of routing observations. Its AS overview response on 5 August 2026 associated resource 24940 with HETZNER-AS Hetzner Online GmbH and marked the autonomous system announced. In everyday language, route collectors could see AS24940 participating in the global routing system at that time.

The announced-prefix response covered a stated window from 22 July to 5 August 2026. It contained 94 observed prefix entries: 89 IPv4 entries and five IPv6 entries. A prefix is a compact notation for a block of internet addresses. IPv4 is the older address system; IPv6 is the much larger successor. The observation therefore shows that both address families appeared in the captured routing surface.

The number 94 is not a count of Hetzner customers, servers, products or facilities. It does not say that every address was reachable from every network throughout the period. Route collectors observe from particular vantage points, and routes can change. Some operational arrangements can place addresses and services behind relationships that are not obvious from one origin number.

The snapshot also does not establish legal ownership. Running BGP tells the internet which paths are being advertised. A registry records administrative facts. Route Origin Authorizations in RPKI can add cryptographic statements about which ASN may originate a prefix. None of those sources alone describes an application’s availability or a customer’s contractual rights.

For a non-specialist, the useful lesson is that routing evidence behaves like traffic observation. It can show that a road was visible and signposted from measurement points. It cannot prove that a specific delivery arrived, that every entrance was open or that the road belonged to the party driving on it.

Organizations using Hetzner should still care about this layer. An unexpected change in origin, loss of an expected prefix or stale operational contact can slow diagnosis. Teams should maintain a list of the prefixes and domains that matter to them, understand which provider or customer ASN is expected, and define who investigates a difference. The goal is not to turn every manager into a routing engineer. It is to avoid discovering the dependency only during an outage.

Peering metadata is a useful map, not a capacity guarantee

PeeringDB offers another kind of record. It is a directory in which network operators maintain information about their networks, interconnection policies, exchange connections and facilities. The captured profile names Hetzner Online, links hetzner.com, associates the network with AS24940 and AS-HETZNER, labels its general policy open and classifies its type as Content.

The profile reported estimates of 1,000 IPv4 prefixes and 200 IPv6 prefixes. Those numbers should not be compared directly with the 94 entries in the RIPEstat window as if one source must be wrong. The fields can represent different scopes, estimates and maintenance practices. RIPEstat reported a particular observed set. PeeringDB presented operator-maintained profile information.

Separate PeeringDB endpoints returned 63 network-exchange LAN records across 49 distinct exchange identifiers and 23 facility records across 23 facility identifiers. Every captured exchange-LAN record was marked operational. Individual rows carried different update dates. These are meaningful signs of an extensive published interconnection surface.

They are not proof of current traffic, spare capacity or physical diversity. Two ports at one exchange are not necessarily two independent failure paths. Two facilities can share a metropolitan fibre route, power dependency or upstream provider. A listed connection may be technically operational while a customer route follows a different path. Operator-maintained metadata can also be incomplete or stale.

The right use of PeeringDB is operational orientation. It helps a network team identify where an operator says it is present and how it describes its policy. It can support contact and planning work. It should be combined with current contracts, live telemetry, path tests and provider confirmation before a company treats it as evidence of resilience.

This is an example of the reality layer in practice. A neat map can simplify a complicated system without becoming the system itself. Management should welcome the map and preserve the limits around it.

A data centre is a chain of physical dependencies

Hetzner’s infrastructure documentation lists eight data centres in its Nuremberg park, 22 in Falkenstein and ten in Helsinki. The page describes uninterruptible power supplies, diesel generation and separate power paths within the facilities. It says the data-centre parks connect to the backbone over redundant dark fibre and gives at least 120 Gbit/s for specified links among Nuremberg, Falkenstein and Frankfurt.

These are issuer descriptions rather than an independent engineering audit. They nevertheless help explain the control surface. A cloud server may look purely virtual in a browser, but it ultimately depends on a physical host, switches, power distribution, cooling, fibre, external connectivity and people who can reach the equipment.

Redundancy has to be interpreted precisely. Two power supplies can protect against one equipment fault, but not every upstream electrical event. Two fibres can protect against one cut only if they are physically separated where it matters. Several sites can protect against one building failure only if the application, data and control plane can move between them.

A customer does not need access to private facility diagrams to make sensible decisions. It does need to know the product’s location, which failure domains are included, which are excluded and what the application does when one disappears. A backup in another rack may survive a server fault. A backup in another fire zone may survive more. A tested copy in another region may address a wider event, but introduces data, latency, compliance and operational questions.

Physical dependencies also affect repair time. A failed component may require a technician, a spare, safe access and a maintenance procedure. A network incident may involve an exchange, a long-haul carrier or a third-party data centre. A status message can communicate progress, but it cannot shorten every external repair.

This is why a buyer should avoid the phrase “the cloud is redundant” without a noun. Which component is duplicated? Across which boundary? Who controls the switch? When was failover tested? What capacity remains after the failure? Which data was present on the surviving side? Specific questions turn a reassuring adjective into an operating design.

The 99.9 percent figure answers a narrower question than most businesses ask

Hetzner’s general terms describe economically reasonable efforts to achieve 99.9 percent annual average network availability at its data centres. Its Cloud and vServer agreement describes commercially reasonable efforts toward 99.9 percent monthly availability for each Cloud Server.

The Cloud Server agreement defines availability through the underlying host, the hypervisor starting the instance and activity visible through system metrics such as CPU or network use. It also lists exclusions, including scheduled maintenance, customer-introduced software or configuration problems, certain attacks, required live migrations and network interruptions outside Hetzner’s reasonable control.

Those details are not fine print to ignore. They define the measurement. A server can meet the stated infrastructure condition while the application is unable to serve users. The operating system may be running while a database is corrupt. A web process may be healthy while DNS points elsewhere. A payment integration may be broken. A customer firewall may reject traffic. The business can be unavailable even when the virtual machine is technically active.

The time scale matters too. An annual network figure and a monthly per-server figure answer different questions. Availability averaged across a period does not tell a company when an interruption will occur or whether several minutes at the busiest hour are tolerable. A business should convert the percentage into an allowed interruption budget and compare it with its own recovery objective.

The agreement describes Cloud Credits as the remedy for qualifying Cloud Server unavailability and limits the scope of that remedy. A credit reduces a future infrastructure bill. It does not replace lost sales, staff time, emergency consulting, customer compensation, missed deadlines or reputational damage. That is normal in many infrastructure contracts, but buyers should price the difference rather than assuming the provider absorbs it.

The correct conclusion is not that 99.9 percent is good or bad in isolation. It is that the number belongs to a specific object, method, period and remedy. Management needs a separate end-to-end objective for the business service. The two figures can inform each other, but they are not interchangeable.

Root access shifts power and responsibility to the customer

Hetzner’s general terms state that customers have full and sole administrator rights for root and cloud server products and are responsible for managing and securing them at their own expense and risk. This is a powerful commercial feature. It gives a customer freedom to install software, choose controls and operate without waiting for a managed-service team.

The same freedom creates work. Someone must patch the operating system, manage access keys, configure the firewall, review logs, monitor disk space, renew certificates, secure the application, test updates and decide when to rebuild. The low invoice does not perform these tasks.

Responsibility can become unclear in a small company. A developer creates a server for a project. The project succeeds. More services are added. The original employee leaves. No one owns the backup or update calendar. The server still responds, so the risk remains invisible. A later incident exposes an expired credential, unsupported package or undocumented dependency.

Larger organizations face the same problem at scale. Teams can create resources faster than a central inventory is updated. Accounts, projects and API tokens multiply. Different units choose different conventions. Cost controls may remove a resource that another team quietly depends on. A deletion-protection setting can help, but it does not replace ownership and change review.

The practical control begins with an owner for every production service. The owner should know which account pays for it, which people can change it, which domains and data stores it needs, which alert reaches an on-call person and which recovery test proves success. Infrastructure-as-code can make configuration repeatable, but it still needs review, secrets management and a recovery path when automation fails.

Low-cost infrastructure is most valuable when a company deliberately budgets for this operating layer. Otherwise, the missing labour appears later as incident cost.

DDoS filtering reduces one risk without removing the rest of the chain

Hetzner’s technical and organizational measures describe continuously active DDoS recognition and automatic filtering of malicious traffic. DDoS means distributed denial of service: many systems send traffic or requests in an attempt to overwhelm a target. Provider-side detection and filtering can prevent or reduce a category of disruption before it reaches a customer server.

The description is useful but bounded. Not every outage is a DDoS attack. An application can exhaust its own database pool under legitimate demand. A customer firewall can block good traffic. A software defect can create a request loop. DNS can fail. An upstream network can become unreachable. A login endpoint can be abused at a scale too small to resemble a volumetric attack but large enough to affect users.

Filtering can also involve trade-offs. A protective system must distinguish harmful traffic from valid traffic. Customers may need to provide packet captures, timestamps or source information when behavior is unclear. An attack can shift from one method to another. The presence of filtering therefore belongs in the control map, not in a claim of immunity.

Businesses should decide which symptoms their own monitoring can see. Provider status and network telemetry may show a broad event. Application metrics can show error rates, queue depth and latency. Synthetic tests can confirm that a user journey works from several networks. Security logs can show rejected connections. Independent observations help teams separate provider, application and customer-configuration causes.

An incident plan should also define authority. Who contacts Hetzner? Who can change firewall rules or scale capacity? Who decides whether a change creates more risk than the attack? Who records the evidence? Speed matters, but so does the ability to reverse an emergency action cleanly.

Backups are a product feature only after they become a recovery process

Hetzner’s documentation describes cloud backups as daily disk copies with seven available slots when the option is enabled. It describes snapshots as customer-created disk copies that remain until deleted. The backup FAQ says backups cannot be protected against deletion and are deleted with the server, while snapshots can use deletion protection.

Those differences are operationally important. A daily backup may limit data loss compared with having no copy, but the acceptable loss depends on the application. A busy database can change thousands of times between backups. A disk image taken while data is being written may need application-aware steps to ensure consistency. A copy can be present yet unusable because credentials or encryption keys are missing.

Location rules also matter. The FAQ describes European backups usually being stored in a different data centre within the location and snapshots being assigned within the same network zone. It also notes different conditions for places that use one data centre, including some US and Singapore locations. “Different server” and “different disaster domain” are not the same claim.

The general terms require customers to make regular backups and store them outside the server provided by Hetzner. The technical documentation explicitly recommends independent backups for several products. This is a clear responsibility signal. A provider feature can be one layer, while the customer preserves a separately controlled copy for broader failure, account or operational risks.

A useful backup policy answers six questions. What data is copied? How often? Where is it stored? Who can delete or restore it? How long is it retained? When was a complete restore last proved? The last question is the most neglected. A green backup job confirms that a process wrote something. A restore exercise confirms whether people can recover the service.

The test should go beyond booting a machine. Restore data, reconnect dependencies, recover secrets through an approved path, point a test name at the service, run representative transactions and measure time. Record manual steps and unexpected decisions. Each exercise turns an assumption into evidence and reveals where the recovery cost actually sits.

Location is part of resilience, latency, law and support

Hetzner documentation distinguishes its own European data-centre parks from third-party data-centre arrangements used in the United States and Singapore. It states that Hetzner Online GmbH remains the customer’s contractual partner while subsidiaries or third-party facilities support the selected location.

This does not make one model inherently safer than another. It shows that “Hetzner Cloud” contains location-specific physical and contractual layers. A workload in Germany, Finland, the United States or Singapore can have different latency, facility dependencies, data-transfer implications and legal considerations.

Location choices should follow the application. A customer-facing service may need proximity to users. A regulated data set may need a specific jurisdiction. A disaster-recovery copy may need enough distance from the primary system. A support team may need to understand which maintenance calendar and escalation path applies.

Moving is not always a button click. The cloud FAQ says an existing server cannot simply change location; a new server can be created from a backup or snapshot where the rules allow. The application may also contain external IP allowlists, certificates, DNS records, queues or databases that need coordinated change.

This is integration work. A migration plan should inventory every address and dependency, lower DNS time-to-live where appropriate, replicate data, test the target, preserve a rollback point and define when the old system can be removed. The infrastructure copy is only one step.

For management, the useful question is not merely “Which region is cheapest?” It is “Which combination of location, user experience, legal boundary, recovery option and operating skill produces the lowest acceptable total risk?”

Monitoring must distinguish infrastructure health from user success

Monitoring is often discussed as if installing one agent solves observability. A reliable service usually needs several views. Host monitoring can show CPU, memory, disk and network activity. Application monitoring can show request errors, response time and queue depth. External checks can show whether users can reach the service. Business checks can show whether an order, upload or login completed.

These views answer different questions. A host can be healthy while the application is stuck. An application can respond internally while a firewall blocks outside users. The home page can load while checkout fails. A provider status page can be green while one customer’s configuration is wrong.

The alert should reach a person who can act. A mailbox that nobody watches is not an incident response process. Teams need severity rules, on-call coverage and escalation. They also need protection against alarm fatigue. If every short spike wakes someone, real warnings can be ignored.

Good incident records preserve timestamps and boundaries. When did the user impact begin? When did monitoring detect it? Which layer failed? Who had authority to change it? What action restored infrastructure? What test proved the business service? This sequence allows management to improve the system rather than argue about a single uptime number.

Public network records can join the monitoring picture. An unexpected origin for a protected prefix, a lost route, a changed registry contact or a certificate problem can be an early signal. The alert should trigger verification, not a public accusation. Automated observations need a human process for context and false positives.

A practical responsibility map for ordinary incidents

Consider a cloud server that stops responding. Hetzner may control the physical host, hypervisor and core network. The customer controls the operating system, software, firewall and application. The first task is not blame. It is to determine which layer shows evidence of failure and which party has the next action.

If the provider reports a host event, the customer still needs a continuity decision. Can the service fail over? Should it wait for recovery? Is the data current on another instance? Who communicates with users? Provider repair and business response happen in parallel.

If the operating system exhausted disk space, the server may remain technically active while the application fails. The customer needs monitoring, safe cleanup and perhaps capacity policy. A provider availability metric does not resolve the application condition.

If DNS points to an old address, both the original and replacement server can be healthy while users reach the wrong place. The domain registrar, DNS provider, cache behavior and deployment process become part of the incident. Ownership must be mapped before an emergency.

If a backup exists but a key is unavailable, data recovery stops at an administrative boundary. The company needs a controlled break-glass process that does not leave credentials exposed during normal operation.

If an upstream path is disrupted, AS24940 may remain visible from some observers while particular users cannot reach it. Multiple external checks and provider evidence can narrow the scope. The customer may choose another region, provider or delivery path if the business impact justifies it.

If an account is compromised, the attacker may use legitimate administrative interfaces. Multi-factor authentication, restricted tokens, audit logs, deletion protection and independently controlled backups address different parts of that risk. No single feature covers them all.

The responsibility map should be written before these events. It does not need to be long. For each critical service, name the provider-controlled layers, customer-controlled layers, shared handoffs, evidence sources, decision owner and recovery test.

Why the cheapest server can support an expensive service

Infrastructure price is visible and easy to compare. Operational cost is spread across people and time. A company may spend more on engineering, security, monitoring, backups and incident recovery than on the server itself. That is not necessarily waste. It is the cost of turning raw capacity into a dependable service.

Integration cost appears when the server connects to identity, email, payments, storage, analytics and customer networks. Each dependency has credentials, quotas, maintenance, failure modes and support contacts. A low monthly instance price does not reduce the number of relationships.

Supervision cost appears in patching, access review, vulnerability response, capacity planning, backups, certificate renewal and on-call work. Automation can reduce repetitive labour, but automation itself needs design, testing and ownership.

Failure cost appears as lost transactions, idle staff, delayed work, emergency consulting and customer communication. The value per minute can vary widely. A personal test site and a hospital scheduling service should not use the same continuity budget merely because they run on similar virtual machines.

Migration cost matters too. A company may choose Hetzner for price and later discover application assumptions tied to particular addresses, storage behavior or tooling. Portability is not created by claiming that containers can run anywhere. It requires data movement, configuration, secrets, network policy and a rehearsed cutover.

The sensible financial model combines these categories. Start with the infrastructure bill. Add the people and tools needed for ordinary operation. Estimate the frequency and impact of likely failures. Add the cost of recovery exercises and alternative capacity. Compare that total with the value and risk tolerance of the service.

Hetzner can remain attractive under this model. The point is not to inflate cost or discourage use. It is to prevent a low invoice from being mistaken for a complete operating system.

Questions a buyer should answer before production use

Start with identity. Which Hetzner legal entity and account are involved? Which project owns each resource? Who receives notices? Are registry, DNS and billing contacts current? Who can recover the account if the usual administrator is unavailable?

Ask what the availability figure measures. Is the business relying on annual data-centre network availability, monthly Cloud Server availability or an internal application objective? Which exclusions apply? What evidence must be submitted for a credit? Which losses remain the customer’s responsibility?

Ask about failure domains. Are primary and secondary systems on different hosts, data centres, regions or providers? Which power, network, identity and DNS dependencies are still shared? Is the remaining capacity sufficient when one side is unavailable?

Ask about data. Which backup option is enabled? How many versions exist? Can someone delete the server and the backups together? Is there a separately controlled copy? Where are encryption keys and restore instructions? When did a full restore last pass?

Ask about access and change. Is multi-factor authentication required? Are API tokens limited? Are production changes reviewed? Does deletion protection cover critical resources? How are emergency actions logged and reversed?

Ask about monitoring. Does the team see provider status, host state, application behavior and user transactions? Are checks run from more than one network? Who is on call? Which alert is allowed to wake someone?

Ask about dependencies. Which DNS, registrar, certificate, database, email, payment, identity and external API services can stop the product? Who owns each contract and escalation path? Which dependency has no tested alternative?

Ask about exit. Can the team rebuild the service from documented configuration and independent data? How long would data transfer take? Which provider-specific features need replacement? When was a migration or disaster simulation last completed?

These questions do not assume that Hetzner lacks a control. They define the evidence a customer needs. Clear questions make provider capabilities more useful because they connect each feature to a real operating objective.

What management should watch after launch

Watch inventory drift. Every production resource should have an owner, purpose, environment, data class and retirement date. Compare the live account with the configuration repository and cost records. Unowned resources are both a security risk and a continuity risk.

Watch backup evidence. Track successful jobs, age of the newest copy, failed snapshots and restore-test results. A long sequence of green backup icons should not substitute for a recent successful recovery.

Watch access. Review privileged users, API tokens and break-glass credentials. Confirm that departing staff lose access and that at least two authorized people can respond without sharing accounts.

Watch application service levels. Report user errors, completed transactions and recovery time alongside provider status. Distinguish “server active,” “application responding” and “business service verified.”

Watch routing and naming signals. Unexpected AS origins, missing expected routes, stale registry contacts, DNS changes and certificate expiry should trigger bounded investigation. Preserve the difference between an alert and a conclusion.

Watch change quality. Measure failed changes, emergency work and rollback time. A reliable team learns whether incidents came from provider infrastructure, customer configuration, dependencies or an interaction among them.

Watch concentration. The same account, region, DNS provider, identity service or human administrator can become a hidden single point of failure. Redundancy should be assessed across control and authority, not only compute instances.

Watch total cost. Combine cloud spend with labour, monitoring, backup storage, data transfer, incidents and recovery exercises. Cost control that removes the only useful backup can increase expected loss. Resilience spending that protects a low-value test system can also be excessive. Match the control to the business consequence.

The practical conclusion

The public evidence supports a careful conclusion. Hetzner Online GmbH has a visible network identity through AS24940. RIPE NCC records the ASN and company relationship. A 5 August 2026 RIPEstat snapshot showed the autonomous system announced and returned 94 observed prefix entries. PeeringDB presents a broad operator-maintained interconnection and facility footprint.

Hetzner’s own documentation describes interconnected data-centre parks, DDoS filtering, cloud backup and snapshot features, and specific availability commitments. Its legal and technical documents also make the boundary visible. Root and cloud customers administer and secure their systems. Customers need backups. Product and location details differ. Infrastructure availability is defined more narrowly than an end-to-end business outcome.

This is not a criticism of affordable infrastructure. It is the reason affordable infrastructure can be used responsibly. A capable provider supplies physical, network and platform controls. A capable customer supplies architecture, configuration, observation, independent data, recovery practice and business verification.

For a non-specialist decision-maker, the rule is simple. Treat the registry as an identity ledger. Treat route data as time-bounded running evidence. Treat peering records as an operator-maintained map. Treat an SLA as a precise contract for a specific object. Treat a backup as unproved until it restores. Treat a running server as only one step toward a working service.

The expensive part of low-cost cloud is not necessarily the hardware. It is the discipline required to know what exists, who controls it, how it can fail and how the organization will prove recovery. That discipline is portable. It protects the business whether the next server runs at Hetzner, another provider or its own facility.

Sources

Image attribution

Generated photorealistic editorial image for BTW Media: a generic network technician checking an unbranded rack in an ordinary data-centre aisle. The source was generated with the built-in image generation tool and converted to a 1600 × 900 JPEG without changing the scene. No real company facility, employee, customer, dashboard, logo or proprietary system is represented. The image does not depict or imply Hetzner Online GmbH, its facilities, its equipment, its service performance, an incident or endorsement.