Summary

  • WebJanssen has a live hosting and communications business, but the name in this article is no longer the name displayed by its own legal notice. The company site says the headquarters moved to Miami Platja, Spain, on 1 October 2025 and the official designation became WebJanssen U.Janssen. RIPE registration and several older commercial pages still use WebJanssen ISP ltd & Co KG or WebJanssen ISP UG. A buyer should verify the contracting party rather than assume that brand continuity means legal continuity.
  • AS29471 is active. RIPEstat observed three IPv4 announcements on 11 July 2026: 195.140.208.0/22, 195.225.208.0/22 and 195.158.54.0/24, covering 2,304 addresses. All were visible to every IPv4 full-feed peer in RIPE RIS at the observation time. The same view showed no IPv6 announcement.
  • Current route evidence shows one adjacent network, Aixit AS29551, for all three prefixes. WebJanssen's RIPE policy record describes KleyReX and numerous historical peers, while an older PeeringDB entry lists two Frankfurt facilities, but neither establishes a second current upstream. Logical and physical route diversity should therefore be treated as unproven.
  • WebJanssen identifies its data-centre location as care of Aixit at Rebstoeckerstrasse 55 in Frankfurt. Aixit describes redundant building entrances, 20 carriers, nearly 1,000 Gbit/s of aggregate bandwidth, more than 300 peerings, UPS, emergency generation and redundant network design at that site. Those are host-facility capabilities, not evidence that WebJanssen buys two independent carrier paths, dual power feeds or reserved capacity from all of them.
  • The retail offer makes recovery an economic choice. WebJanssen advertises virtual servers limited to 10 or 100 Mbit/s, optional image backup, a standard response within one business day and paid service levels with a four-hour response. Its legal notice says out-of-hours emergency service incurs hands-on charges. Customers affected by an upstream loss, host failure, power incident or shortage of available technicians need the contract to say who responds, from where and within what time.
  • The network is demonstrably operating, but the resilience evidence grade is Weak. One visible upstream, no routed IPv6, route-origin protection for only one of three prefixes, old interconnection records and no published restoration record leave too much uncertainty to claim a resilient regional access network. The evidence instead supports a small Frankfurt-centred hosting network operated under a cross-border commercial identity.

The name survived while the contracting identity changed

The first problem is not packet loss. It is identifying who promises to restore the service. The name WebJanssen ISP ltd & Co KG remains attached to AS29471 in the RIPE RDAP record, and it is the existing name under which the company is commonly found. Yet WebJanssen's own news page says its headquarters moved to Spain on 1 October 2025 and that its official designation became WebJanssen U.Janssen. The current legal notice gives an address in Miami Platja, Tarragona, and a Spanish tax identifier.

That is not a cosmetic footnote. A customer may use the brand, the autonomous-system name and the contracting company interchangeably in conversation, but those labels answer different questions. The brand tells the customer where to seek help. The AS registration tells other networks which routing identity originates the addresses. The contract determines who owes the service, who invoices it, which law applies and who must organize a repair. When those labels diverge, the buyer needs current documents that join them explicitly.

The public pages do not do that cleanly. WebJanssen's terms and conditions say the contracting party is WebJanssen ISP UG (haftungsbeschraenkt), while the legal notice names WebJanssen U.Janssen. A German commercial-data page describes an active WebJanssen UG, registered in Oldenburg in 2022 to provide telecommunications, hosting, housing, network and administration services and to act as general partner of a WebJanssen partnership. This secondary record supports business continuity in Germany, but it does not resolve which person or company signs a new Spanish-headquartered service agreement in 2026.

There is another historical break. The United Kingdom's Companies House record for WEBJANSSEN ISP LIMITED says that company was incorporated in 2001 and dissolved on 31 March 2020. Its filing history includes dormant-company accounts before the compulsory strike-off. The exact name and shared officers make the record relevant context, but the public evidence reviewed here does not prove the legal role that the UK company once played in the German partnership. It would be unsafe either to ignore the dissolution or to infer that it ended the operating network.

The network evidence points the other way: the service continued. The company website is live, current product pages accept business, the support and customer portals are linked, and AS29471 was visible in global routing data on 11 July 2026. The correct conclusion is narrow. WebJanssen remains an operating brand and network, while the legal identity behind new service commitments needs confirmation. A purchase order should name the current counterparty, tax registration, governing law, service location and entity responsible for data and equipment after termination.

That administrative clarity is part of resilience because an outage is the worst time to discover that the network registration, invoice and emergency contact refer to different legal forms.

The offer is hosting first, not a proven local-access network

The category "ISP" can suggest poles, ducts, fibre drops, wireless towers and field crews driving to customer premises. WebJanssen's current public offer supports a different picture. Its home page leads with webspace, virtual servers, hosted Microsoft Exchange, email archiving and VPN. Its customer area links to separate controls for Windows servers and Exchange, Linux servers, virtual-server administration, webmail and support. These are the interfaces of a hosting and managed-services provider.

The webspace plans offer Linux or Windows environments, domain capacity, mailboxes, databases, FTP access, SSL certificates and control panels. The root-server plans are virtual machines built on Xen, with fixed addresses, remote console functions and optional managed administration. The hosted Exchange page combines mailboxes, spam and virus filtering, calendar and address-book functions, web access and optional archiving. None of these pages offers a map of homes passed, street cabinets, tower sectors, fibre routes or installation crews.

That absence matters because it changes the physical dependency being analysed. A hosted server can be "local" to a German customer in the sense that its rack is in Frankfurt, its telephone support is familiar and its operator is small. It is not a last-mile circuit to the customer's building. The customer still reaches WebJanssen through a separate access provider, local router, office power and public internet path. WebJanssen controls the hosted machine, assigned address, service configuration and its own border routing; it does not thereby control the fibre or mobile connection from every customer to Frankfurt.

The distinction also changes who suffers when the service fails. A root-server outage can take down a customer's website, mail server, game service, name server or business application. An Exchange incident can interrupt communications for a small firm even while ordinary internet access works. A failure of AS29471 can make many unrelated hosted domains unreachable at once. Conversely, a severed local access cable at one customer's office may leave every WebJanssen system healthy while that customer cannot reach it.

WebJanssen's public scale looks consistent with a specialist host. IPinfo's AS29471 view classifies the network as hosting, counts 2,304 routed IPv4 addresses and reports hundreds of hosted domains. The hosted-domain number is an observation, not a customer count: one customer can operate many domains, many domains can share an address, and inactive names can remain pointed at an old server. Still, the combination of hosting products, control panels, mail systems and address use is stronger evidence than the regional-ISP label for understanding the operating burden.

The article title's "local connectivity bill" should therefore be read as the bill for a locally supported hosted connection, not proof of WebJanssen-owned access plant. The consequential assets are racks, host systems, storage, power, cooling, fibre handoffs, border routing, name and mail services, spares and people able to work on them. Towers, poles and customer-premises installations would become relevant only if a specific contract showed that WebJanssen supplied them. No such public evidence was found.

One Frankfurt address anchors the physical service

The strongest location evidence comes from the operator itself. WebJanssen's current legal notice identifies its data centre as WebJanssen U. Janssen, care of Aixit GmbH, Rebstoeckerstrasse 55, 60326 Frankfurt am Main. That is the same address Aixit gives for AIX-FRA-1, its Frankfurt data centre and headquarters. The address connects WebJanssen's commercial pages to a specific facility rather than a generic claim of "German hosting."

Aixit says the building has more than 4,000 square metres of data-centre space, redundant building entrances from 20 carriers, nearly 1,000 Gbit/s of bandwidth and access to more than 300 national and international peers. It describes UPS, cooling, emergency-power and connectivity systems, and says the network design is redundant from the ground up. Aixit's company page says it expanded at the Rebstoeckerstrasse site after moving there at the end of 2018. These claims make the site a plausible physical base for a small network needing racks and carrier choice.

But a facility's menu is not a tenant's configuration. Twenty carriers entering a building does not mean WebJanssen buys transit from twenty carriers. Two building entrances do not prove that its rack has two cross-connects following independent routes. Facility-wide UPS and generator systems do not establish that a particular cabinet has A and B power feeds, that both feeds are used correctly, or that a single-power-supply server can survive loss of one distribution path. Nearly 1,000 Gbit/s of aggregate bandwidth says nothing about the capacity committed to AS29471.

The same caution applies to ownership. Aixit operates the data-centre environment and AS29551; WebJanssen advertises services installed there and originates addresses through AS29471. The public material does not say whether WebJanssen owns its server chassis, leases complete systems, rents rack units, buys a managed platform, or combines those arrangements. It also does not say who owns the optical transceivers and border routers at the handoff. Those boundaries determine who holds spares and who may touch equipment during an incident.

PeeringDB's network record for AS29471 lists two Frankfurt facilities: "aixit Frankfurt" and "Digital Realty Frankfurt FRA28 (Closed)." Its data-centre associations were last updated in 2016, however, and the same record shows no active public exchange connection. The closed-facility label and old update date make the entry useful as history, not a current two-site redundancy claim. It cannot support a conclusion that WebJanssen has two operating Frankfurt locations.

There is no published second WebJanssen data centre in another city, no rack-level power diagram and no declared recovery site. The safest physical view is a Frankfurt-centred service at the Aixit address, with broader facility options available but tenant-specific resilience undisclosed. The Spanish headquarters is a commercial and support location, not evidence that production servers moved to Spain. WebJanssen's own pages continue to put the data centre in Frankfurt after the headquarters move.

AS29471 is active, globally visible and IPv4-only

An autonomous system is not a company, a server or a building. It is a routing identity used to apply policy and originate reachable address space. AS29471 nevertheless provides the best independent evidence that WebJanssen's network is operating. RIPEstat's AS overview marked it announced on 11 July 2026 and named the holder as WebJanssen-DE, WebJanssen ISP ltd & Co KG.

The routing-status view reported three IPv4 prefixes covering 2,304 addresses. All 325 IPv4 full-feed RIS peers in the snapshot saw the routes. The most recent route was observed that morning, and the first route attributed to the AS in RIPEstat's history dates to October 2003. This is strong evidence of continuity at the control-plane edge: the network is not merely a stale business listing or an unused AS number.

The announced-prefix view identified 195.140.208.0/22, 195.225.208.0/22 and 195.158.54.0/24. Each /22 contains 1,024 IPv4 addresses and the /24 contains 256, producing the 2,304 total. Separate RIPEstat network views confirm AS29471 as the origin observed for 195.140.208.0/22, 195.225.208.0/22 and 195.158.54.0/24.

The company website adds a service-level cross-check. RIPEstat's DNS-chain view for webjanssen.de resolved the site to 195.140.208.58, inside the first /22, on 11 July. The public sales site is therefore served from an address currently originated by AS29471. That does not prove where the machine sits, but it connects current commercial activity to the live routing footprint.

No IPv6 prefix appeared in the routing-status view. PeeringDB also lists zero IPv6 prefixes and says IPv6 is unsupported, although that profile was last updated in 2022. France's electronic-communications regulator ARCEP included AS29471 in its 2025 IPv6 hosting barometer and showed zero IPv6 availability for the tested WebJanssen-hosted sample. That test involved a very small sample and is not a full inventory, but it agrees with the current absence of routed IPv6.

IPv4-only operation does not mean immediate outage. Customers can still reach the services over IPv4, and translation mechanisms can bridge some IPv6 access environments. It does mean that the network lacks a native second address family that many contemporary hosts offer. More importantly for resilience, the absence narrows the routing surface: there is no visible IPv6 service that might remain reachable through a separately engineered path if IPv4 policy fails. Dual-stack is not automatically diverse, but single-stack removes even that possibility.

Address count also should not be confused with throughput. The nine /24 equivalents say how much unique IPv4 space is visible, not how many bits per second the network can carry. A mostly idle /22 can have little bandwidth; a busy /24 can carry substantial traffic. Nor does the count establish customers, processors, storage or spare capacity. It confirms a non-trivial, long-lived address footprint suitable for hosting and mail, nothing more.

Every current route points through Aixit

The central concentration appears one hop outside AS29471. RIPEstat's ASN-neighbours view showed one unique adjacent network on 11 July 2026: AS29551. The observed position places AS29551 to the left of WebJanssen in paths toward the global table. bgp.tools independently lists Aixit AS29551 as the only upstream for all three IPv4 prefixes and counts one upstream.

The one-year RIPEstat routing-history view makes the same dependence explicit. For each of the three prefixes, the observed origin pair is 29551 29471: traffic learned through the collector set sees Aixit immediately before WebJanssen. Route collectors do not see every private interconnection, and commercial contracts are not public BGP paths. Even so, consistent observation across three prefixes is the strongest current evidence available.

The RIPE database AS record contains a much richer policy description. It declares AS29551 as upstream, KleyReX AS31142 as a peering platform and numerous named peers. This could look like broad diversity if read as a live topology map. It is not. The record was last modified in July 2021, and route-policy declarations can outlive sessions, ports and contracts. Current neighbour observations and PeeringDB's zero active exchange count do not corroborate those older peer statements.

KleyReX itself remains active. Its official site describes a switched exchange fabric spanning more than 15 locations and offering ports from 100 Mbit/s to multiple 100 Gbit/s. That establishes an available Frankfurt peering environment, not WebJanssen's current participation in it. A line in an old routing record shows intent or history; a current port, exchange member record or observed peer path would be needed to count it as a working alternative.

Aixit is not an arbitrary upstream. Its Frankfurt site is also the data-centre address WebJanssen publishes. That colocation can make operations efficient: a tenant can buy a short cross-connect, reach the provider's network without a long tail circuit and obtain hands-on help near the equipment. It also creates a common boundary. If WebJanssen's servers, border handoff and only visible upstream all depend on one provider at one building, an Aixit network incident or a site-level event can affect both hosting and carriage together.

The public data cannot establish that this common boundary is total. WebJanssen may have a private connection hidden from route collectors, a dormant backup, a tunnel, or another service that does not announce the three prefixes. Those possibilities should not be treated as operating safeguards until tested. Resilience purchasing cannot rely on paths that appear only after an outage unless the provider can show that they are provisioned, monitored, authorized to originate the prefixes and capable of carrying peak traffic.

Route-origin protection covers only one of three announcements

Routing concentration is not the only control-plane issue. Resource Public Key Infrastructure allows an address holder to publish a Route Origin Authorization stating which AS may originate a prefix. Other networks can compare an announcement with that authorization and reject or de-preference invalid origins. RIPE NCC's BGP origin-validation explanation describes this as a way for operators to set policy according to route-origin validity.

For WebJanssen, the current result is mixed. RIPEstat reports 195.158.54.0/24 as valid for origin AS29471. The RPKI history for AS29471 showed one authorization covering 256 addresses in early July 2026. In other words, the protected space is the /24, about 11 per cent of the 2,304 routed IPv4 addresses.

The other two routes were unknown for 195.140.208.0/22 and unknown for 195.225.208.0/22 at the same check. Unknown does not mean invalid. It means no matching validated authorization covered that origin and prefix, so origin-validating networks cannot use a positive authorization to distinguish the legitimate AS29471 announcement from an unauthorized origin solely through this control.

Even the valid /24 is not made outage-proof. Origin validation does not prove the whole AS path, ensure that packets reach the correct server, prevent every route leak or preserve service during an upstream failure. It reduces one class of routing error or attack. Its practical value also depends on other networks enforcing validation. Still, coverage is a measurable hygiene control, and covering one of three announcements leaves a clear improvement opportunity.

The combination of single observed upstream and partial origin protection deserves attention because each addresses a different risk. A second functioning upstream can preserve reachability when one carrier fails. An authorization can help other networks reject an unauthorized origin. Neither substitutes for the other. Adding an authorization would not create a second physical path; buying another carrier would not automatically authorize the new routing arrangement or protect against an incorrect origin.

A buyer need not demand access to router configurations. It can ask for a current list of originated prefixes, authorization status, upstream AS numbers, tested failover behavior and the date of the last loss-of-transit exercise. The answer should separate production paths from old registrations. In WebJanssen's case, public routing observations support one production path and one authorized prefix, so stronger claims require direct evidence.

Facility capacity is not WebJanssen capacity

Aixit's facility claims are impressive relative to WebJanssen's advertised retail limits. Nearly 1,000 Gbit/s of site bandwidth and more than 300 peerings describe a large connectivity marketplace. WebJanssen's root-server products, by contrast, advertise flat-rate traffic at 10 Mbit/s for the private and business tiers and 100 Mbit/s for professional and managed tiers. PeeringDB describes AS29471's traffic level as 20-100 Mbit/s, though that self-reported range was last updated years ago.

These figures occupy different layers. The facility number is aggregate installed capability across many customers and networks. The virtual-server number is a per-product limit. The PeeringDB range is an old categorical estimate for traffic exchanged by AS29471. None shows current utilization on WebJanssen's upstream port, the committed information rate bought from Aixit, burst capacity, packet loss under load or spare headroom after a failure.

Usable capacity during an incident can be much smaller than normal installed capacity. Suppose a provider has two 100 Mbit/s links and normally sends 60 Mbit/s over each. Losing one leaves 100 Mbit/s for 120 Mbit/s of demand, so a topology that looks redundant still congests. In WebJanssen's public case, the premise is even less certain because a second current link is not visible. The remaining path must absorb all traffic only if a remaining path exists.

Server limits introduce another bottleneck. A customer buying a 10 Mbit/s virtual server cannot infer faster recovery or more headroom from the data centre's terabit-scale aggregate. Storage input/output, hypervisor scheduling, backup traffic, firewall capacity and denial-of-service filtering can each become the binding constraint before the upstream port fills. The product pages specify virtual CPU, memory, disk and traffic rates but do not publish contention ratios or measured performance.

The IPv4 inventory is similarly not a capacity reserve. Addresses can be allocated without consuming bandwidth, and exhausted addresses can constrain customer growth even when links are idle. WebJanssen advertises one fixed address on standard root servers and up to five on some managed products. That use is consistent with hosting, mail and name-service workloads. It does not reveal how much of the 2,304-address footprint remains assignable.

For a business customer, the useful commercial specification is therefore service-specific: committed and burst throughput, congestion policy, denial-of-service handling, backup-window effects, packet-loss and latency objectives, and capacity available after the largest single failure. A facility brochure can show that expansion options exist. It cannot show that they have been bought for a particular server.

Power redundancy ends at the weakest plug

The Frankfurt building is the main common physical dependency. Aixit says AIX-FRA-1 uses modern UPS, emergency-power, cooling and connectivity technology, with redundant network design and multiple building entrances. Its main company site also says its data centres are ISO 27001 certified and powered by renewable energy. These are useful host claims, but WebJanssen does not publish the rack configuration that would turn them into an end-to-end service guarantee.

Power resilience is a chain. Utility feeds enter the building, switchgear distributes them, UPS systems bridge interruption, generators sustain longer outages, rack power units feed devices, and each server or router converts that supply. Redundancy at one point can be defeated at the next. A dual-fed rack does not help a device with one power supply connected to one strip. Two supplies connected to the same strip do not create path independence. A generator does not guarantee continuity without fuel, maintenance, automatic transfer and successful load testing.

WebJanssen's product pages do not state whether root-server host systems have dual power supplies, whether border routers are paired, or whether storage replicas sit in separate fire and power zones. Xen virtualization can move or restart workloads under some designs, but WebJanssen's claim that Xen makes the servers highly failure-resistant does not disclose clustering, live migration, shared-storage failure domains or spare-host capacity. Virtualization changes how a machine failure is handled; it does not remove the physical host beneath it.

Cooling is equally consequential. A data hall can retain utility power while temperatures rise after chiller or air-handling failure. Emergency generation must support enough cooling as well as IT load, or servers will shut down to protect themselves. Aixit says the site uses current cooling and redundant design, but neither party publishes WebJanssen-specific temperature thresholds, failover tests or shutdown behavior.

There is also a geographical issue. The official business address is now in Spain and the data centre in Germany. Remote operation is normal in hosting, but it divides authority from physical reach. A person answering the phone may be able to diagnose a failed server yet unable to replace a power supply without Frankfurt access. A facility technician may be able to reseat a cable but lack permission or configuration knowledge to replace a router. The recovery time is the sum of detection, diagnosis, authorization, travel or dispatch, access, parts, repair and validation.

The public evidence supports good facility potential. It does not support a WebJanssen-specific claim of concurrent maintainability, dual-site continuity or autonomous operation through a long regional power event. Customers for whom an hour matters need the rack power, generator autonomy, cooling redundancy, spare-hardware ownership and remote-hands terms written into their service, not inferred from the address.

The service price buys a particular speed of human response

Small providers often compete through familiarity. WebJanssen's home page says support is available by email, ticket or telephone. Its legal notice publishes business hours from Monday to Thursday and shorter hours on Friday, with a chargeable emergency service outside those periods. The root-server page says free extras include a response within one business day, while paid service levels can offer a response within four hours.

This is unusually revealing because it makes labour part of the product. A virtual server at EUR19.99 or EUR49.99 per month does not include the same response obligation as an engineered high-availability platform. Optional backup and optional faster response allow a low headline price, but they also leave more recovery risk with the customer. The cheapest server may be entirely suitable for a hobby site; it is a different proposition for payroll, customer email or a transaction system.

Response time is not restoration time. A four-hour response can mean that an engineer acknowledges the ticket, begins diagnosis or communicates a plan. It does not necessarily mean the service will be working within four hours. A business-day response can extend across a weekend depending on when the fault occurs. The public pages do not define severity levels, clock start, escalation, credit, parts replacement, target restoration or maximum number of simultaneous incidents.

The phrase "hands-on fees" in the legal notice is also significant. It suggests that some out-of-hours intervention is billable physical work rather than an automatically included round-the-clock service. The page does not identify whether those hands belong to WebJanssen staff, Aixit staff or another contractor. All can be effective arrangements, but they have different queues and authority. A data-centre technician may serve many tenants during a facility-wide event; an owner-operator may know the network deeply but have limited parallel capacity.

No current public headcount, shift roster, spare inventory or dispatch record was found. It would be wrong to infer poor support from that silence. It would be equally wrong to infer a staffed 24-hour network-operations centre from a telephone number. The available evidence supports reachable business-hour support, optional faster response and chargeable emergency intervention.

This labour boundary is where the cross-border structure becomes operationally important. Diagnosis can occur from Spain, routing can be changed remotely and software can be restarted from a control panel. Failed optics, drives, power supplies, cables and host systems still require someone at or near Frankfurt. The resilience of a low-cost hosting bill therefore depends on whether trained hands and compatible spares are available when multiple customers need them at once.

Five failures reveal what the invoice leaves unsaid

The first test is loss of Aixit transit. Current public paths show AS29551 immediately upstream of AS29471 for all three prefixes. If that BGP session, handoff or provider path fails and no hidden backup is active, the prefixes can disappear from the wider internet even while every WebJanssen server remains powered. Recovery would require restoring the session, moving announcements to a pre-authorized alternative or repairing the shared handoff. An old KleyReX policy line is not sufficient evidence of such a fallback.

The second is a facility or power event at Rebstoeckerstrasse. A building incident can affect host systems, border equipment and the adjacent upstream together. UPS and generation can reduce the probability of interruption, but the public evidence does not show separate WebJanssen sites or a live copy elsewhere. Customers whose applications exist only on one virtual server may lose both compute and connectivity at the same time.

The third is a host, storage or hypervisor failure. Xen can isolate virtual machines and permit flexible management, but a failed host still needs spare capacity for restart or migration. Shared storage can preserve data while becoming a common failure point; local storage can isolate failures while complicating recovery. WebJanssen sells optional image backup but does not state recovery-point or recovery-time targets. A backup that exists but has not been restored under realistic conditions is potential recovery, not proven recovery.

The fourth is congestion or attack. A 10 or 100 Mbit/s product can be overwhelmed well below the facility's aggregate capacity. A denial-of-service event can saturate the customer limit, WebJanssen's handoff or an upstream filter. The public offer does not quantify mitigation capacity or scrubbing arrangements. Customers should distinguish an unlimited-traffic billing label from unlimited instantaneous bandwidth; a traffic flat removes a usage meter, not a physical rate limit.

The fifth is labour shortage during a broad incident. One failed disk on a weekday may be simple. A utility event, cooling alarm or network fault affecting many tenants can create simultaneous tickets and physical tasks. The first available technician must prioritize, obtain access and locate parts. Neither a business-hour hotline nor a four-hour response promise says how many incidents can be handled in parallel.

Several other failures can sit above this infrastructure. A customer can misconfigure DNS, lose credentials, allow a certificate to expire or delete data. A local access carrier can fail while the hosted service remains healthy. The aim is not to assign every problem to WebJanssen; it is to separate responsibility so each failure has an owner and a tested recovery path.

What a resilience claim would need to show

For upstream diversity, the decisive evidence would be a second current carrier or exchange connection carrying production routes, visible in current observations or demonstrated in a controlled failover. The second path should be checked for shared ducts, entrances, meet-me rooms, power and upstream dependencies. Two BGP sessions delivered over one cross-connect protect against some router failures but not a severed cable.

For routing security, the two unknown /22 announcements could be covered by appropriate origin authorizations if the address holders and operational arrangements permit it. Current route objects, prefix filters and contacts should match the production topology. Historical policy statements should be removed or clearly distinguished so that customers and peers do not mistake them for live capacity.

For facility continuity, WebJanssen would need to identify whether critical devices have dual power, whether host capacity survives one chassis failure, where backups reside and how long generation and cooling can carry the relevant load. A second-site copy would need an independent failure domain and a tested activation method. Merely naming another building or storing backup media elsewhere would not establish application recovery.

For labour, useful evidence would include severity definitions, acknowledgment and restoration targets, out-of-hours authority, remote-hands ownership, spare-part coverage and the result of recent repair exercises. The buyer should know whether the four-hour commitment applies continuously or only in certain windows and whether it ends at first response.

For commercial continuity, the next contract should reconcile WebJanssen U.Janssen, WebJanssen ISP UG and the name attached to AS29471. It should identify which party controls customer data, domains, addresses and equipment, and which party remains responsible if a subcontractor or facility operator changes. The question is not whether a historic name can remain in a routing registry. It is whether the current signer can command every dependency required to restore the purchased service.

None of these requests requires a small operator to publish sensitive diagrams. A concise assurance letter, current service schedule and witnessed failover result can establish much more than a marketing adjective. The standard should scale with the customer's consequence of failure: a brochure site may need little more than restorable backup, while a business mail platform needs tested recovery, clear escalation and alternate communications.

The economics reward clarity more than scale

WebJanssen's prices make visible why specialist hosting persists. A small firm can buy a managed Linux or Windows environment, mailboxes, domains and telephone support without staffing its own server room. The provider can spread a Frankfurt rack, upstream handoff, software licences and engineering knowledge across many customers. Aixit's larger facility spreads power, cooling, security and carrier access across many tenants. Each layer converts lumpy infrastructure into a monthly bill.

The same layering can obscure concentration. WebJanssen may appear to offer server, connectivity, email and backup as different products, but they can share the same building, upstream and technicians. A customer may purchase several services and believe it has diversity when all fail together. Low price is not the problem; unexamined common dependencies are.

Optional backup and faster response are economically rational. Not every workload deserves synchronous replication or immediate intervention, and charging every customer for the highest level would make basic hosting uneconomic. The important point is for the customer to buy deliberately. An optional image backup should state frequency, retention, location and restoration responsibility. A paid response should state what action occurs and what happens if hardware is unavailable.

Peering could also improve small-network economics by keeping some traffic off paid transit, shortening paths and reducing upstream dependence. WebJanssen's older RIPE policy points to KleyReX, whose free basic peering offer is designed for precisely this sort of operator. Yet current observations do not show an active exchange connection. The economic opportunity is not the same as an installed safeguard.

The facility offers another expansion path. Aixit says it can provide cross-connects to major carriers and exchanges, so WebJanssen is located where additional diversity may be obtainable. Whether buying it is justified depends on customer revenue at risk, the cost of a second port and the operator's ability to support the added complexity. A second path that is never monitored or exercised can create false confidence and routing mistakes.

For customers, the fair comparison is total continuity cost rather than the server line item. That includes access to Frankfurt, application backup, alternate email or status communications, recovery labour and the revenue impact of downtime. WebJanssen can remain competitive without imitating a hyperscale provider, but its strongest proposition would be precision: what is included, what is shared, what is optional and how failure is handled.

A live specialist network with weak resilience disclosure

The operating-status question can be answered more firmly than the resilience question. AS29471 is active, its three IPv4 routes were globally visible, webjanssen.de resolves into one of them, the sales and support pages remain available, and the operator names a current Frankfurt data-centre address. The October 2025 headquarters announcement is recent. These facts support a continuing business, not an abandoned network.

They do not support the picture implied by a broad regional-ISP category. There is no public evidence of owned last-mile fibre, wireless towers, customer drops, local access licences or field crews serving an access territory. The evidence supports a hosting and communications specialist whose public network is centred in Frankfurt and whose commercial address is now in Spain. "Global" describes internet reach and PeeringDB's old scope field better than it describes a documented physical service area.

The resilience evidence is Weak because the remaining unknowns sit on the critical path. One observed upstream carries all three prefixes. No IPv6 route is visible. Only one prefix has positive route-origin authorization. Peering and facility data are old or self-reported. The host facility advertises strong general capabilities, but no WebJanssen-specific power, route or second-site design is published. Human response is described in hours, but restoration, shift depth and parts are not.

Weak evidence is not a prediction of failure. It is a limit on what can responsibly be claimed. A small, experienced operator at a capable Frankfurt facility may deliver reliable service for years. The public record simply does not establish independence from Aixit, recovery through a major common-mode event or immediate physical response outside normal hours.

That distinction should shape the purchase. A low-consequence website can accept the concentration and maintain a portable backup. A business-critical customer should obtain the current legal counterparty, route design, power arrangement, backup recovery terms and technician commitment before relying on the connection. The monthly bill is local and simple; continuity depends on a chain that crosses a Spanish headquarters, a Frankfurt rack, one visible upstream and the hands available when something physical breaks.