kCore Cloud LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• kCore Cloud has a verifiable operating surface. Its website accepts shared-hosting orders, its customer portal published an emergency-maintenance notice in May 2026, ARIN identifies it as the holder of AS401197 and two address allocations, and RIPEstat observed both its IPv4 and IPv6 routes across all reporting full-feed peers in July 2026.
• The visible network is compact and concentrated. AS401197 originated one IPv4 /24 and one IPv6 /40, with AS4213 as its only observed neighbour. The IPv6 route had valid route-origin authorization, while the IPv4 route returned an unknown status because no validating authorization was found.
• The company's claim that it owns hardware and has its own data-centre space is plausible but not sufficiently located. Its corporate site uses an AS4213 address inside a block registered as KRYPT-IAD1, and low-latency measurements from Ashburn point toward Northern Virginia, but no public company page identifies a facility, rack count, power design, spare inventory or alternative production site.
• The published 99.9% annual network guarantee excludes scheduled maintenance, emergency work, hardware or software failures fixed within an hour, denial-of-service attacks, support work and several other outage classes. It is therefore a limited financial remedy, not proof that a website, mailbox and control panel can all recover within a customer's required time.
• Backup and locality risk are explicit in the contract. Customers are required to keep an independent copy; a hosted backup may be unavailable or corrupt; and account data or backups may move to another data centre, state, country or continent. A US ASN and Texas address do not establish where every customer copy rests.
• The evidence grade is Medium. Current routes, live commerce and a recent operational notice establish that the company is active, but the single observed upstream, absent public facility identity, unquantified hardware estate, private network-status view and limited recovery evidence prevent a stronger assessment.

The small-business promise has a physical address, but not yet a physical map

kCore Cloud does not present itself as an immense utility. Its home page says it is a small business with its own hardware and its own data-centre space. Its about page calls it a small company founded by an Internet infrastructure expert. The product currently visible to an unauthenticated buyer is narrower than the word cloud can imply: shared website and email hosting, domain registration, migration assistance and paid technical guidance. The hosting page lists plans with 5GB, 10GB or 40GB of SSD storage, corresponding database allowances and a finite number of email accounts and domains.

That is not a criticism. Shared hosting remains an important infrastructure service for small organizations that do not want to operate a server, patch a web stack, manage mail or negotiate directly with a colocation company. The customer buys an abstraction: a login, a storage quota, a database, a certificate, mailboxes and support. kCore in turn must assemble a much less abstract system. It needs servers, drives, memory, network ports, rack power, cooling, Internet transit, domain services, billing software, monitoring and people able to intervene when one of those parts fails.

The phrase "our own data-centre space" defines only part of that boundary. It suggests a colocation or leased-space model, not ownership of an entire building. In that model kCore may own servers and network equipment while another operator controls the property, utility feeds, generators, uninterruptible power systems, cooling, fire suppression, loading dock, access list, meet-me room and remote-hands service. A network provider may control the external circuits and routers through which AS401197 reaches the Internet. Those arrangements can deliver excellent service.

They also divide responsibility across contracts that a shared-hosting customer may never see.

No public kCore page reviewed for this article identifies a production facility by name or street address. The Houston address in the company's ARIN registration matches the registered address in its legal terms, but a corporate mailing address is not a server location. The site does not publish a rack count, power allocation, current server inventory, storage headroom, facility certificate or second production region. It does not say whether "space" means part of one cabinet, several cabinets, a cage or capacity obtained through a hosting supplier.

This missing map changes how the service should be evaluated. A buyer cannot assume that the Houston legal address is the data location. It cannot assume that two pieces of equipment are in different buildings because they have different IP addresses. It cannot assume that spare disk bays, unused rack units or uncommitted power exist merely because new orders are accepted. The first due-diligence question is therefore simple: identify the facility operator, metro, building, rack footprint and equipment ownership for the service being purchased.

Until kCore publishes or contractually supplies that answer, its physical location remains a well-supported hypothesis rather than a verified customer fact.

AS401197 proves a live edge, not a large estate

The strongest evidence that kCore is more than a storefront is its Internet number-resource footprint. ARIN's record for AS401197 identifies kCore Cloud LLC, records the autonomous-system allocation in June 2024 and points to kcore.net. ARIN's IPv6 record assigns the company the active 2602:f897::/40 allocation, registered in June 2024. ARIN's IPv4 record shows an active direct allocation of 199.184.211.0/24, registered in October 2025. The IPv4 block contains 256 addresses; the IPv6 /40 contains 256 possible /48 customer-sized networks, although address-space mathematics says nothing about how many are in use.

RIPEstat's routing-status view observed one IPv4 prefix, one IPv6 prefix and one neighbouring autonomous system in July 2026. All 326 reporting IPv4 full-feed peers and all 322 reporting IPv6 peers saw the routes in that observation. The announced-prefix view identifies those routes as 199.184.211.0/24 and 2602:f897::/40. This is strong evidence of a globally visible dual-stack network edge.

The timing is revealing. RIPEstat's route history saw the IPv6 route from July 2024, soon after allocation, while the current IPv4 /24 appeared in October 2025. That pattern is consistent with a network that established IPv6 first and added a directly allocated IPv4 block later. It does not show whether customer traffic used another provider's addresses before October 2025, or how much production moved when the /24 appeared. It does show continuing route visibility rather than an allocation left entirely dormant.

The routes also have different origin-security states. RIPEstat's RPKI check for the IPv6 route found a valid Route Origin Authorization permitting AS401197 to announce the /40. The corresponding IPv4 check returned unknown because it found no validating authorization. Unknown is not the same as invalid: it means the cryptographic route-origin system cannot confirm the origin from a matching authorization. Creating a valid authorization for the IPv4 route would remove that avoidable ambiguity.

What the route data cannot reveal is equally important. A /24 can support hundreds of individual addresses or a small number of shared front ends. A /40 can be generously subnetted while only a few hosts respond. BGP does not expose CPU count, drive condition, tenant count, web requests, database load or remaining rack power. It does not show whether a server has two power supplies, whether those supplies enter independent distribution paths, or whether a second machine can absorb its tenants. The network evidence establishes a real operating boundary. It does not turn the company's unquantified hardware claim into a capacity figure.

Independent measurements reinforce that caution. IPinfo's AS401197 page lists the same two address ranges but estimated only one hosted domain and found very few ping-responsive addresses in recent scans. Its June 2026 traceroute from Ashburn reached an address in the kCore /24 after AS4213 with low latency. The IPinfo view of the IPv4 block likewise reports sparse visible domain use. These are unofficial market signals, not a census. Shared hosting can place many names behind one address, firewalls can suppress probes, IPv6 services can ignore unsolicited traffic, and private management addresses will be invisible. The measurements suggest a small public-facing footprint; they cannot prove customer count, revenue, idle capacity or lack of use.

One observed upstream is the clearest concentration

RIPEstat's neighbour data observed only AS4213 on the left side of AS401197 and no downstream autonomous systems. bgp.tools also identifies AS4213, historically registered as Krypt Technologies and now presented publicly as Evocative Global, as the upstream for both IPv4 and IPv6. CIDR Report shows the same single adjacency in collected routes.

This is a concentration, not proof of poor engineering. One provider can deliver two physical circuits, diverse ports and a robust backbone. A second path may exist but remain inactive, private or invisible to the collectors used here. The provider may operate redundant routers and links inside one facility even though the global route table sees one upstream ASN. Conversely, two BGP sessions to AS4213 could still share a conduit, line card, account, metro or facility edge and fail together. Public routing can count autonomous-system paths; it cannot inspect cable trays.

The distinction matters because the home page promises "built-in redundancy." Redundancy must be tied to a failure domain. Mirrored drives protect against some drive faults. Two power supplies protect against one supply only if they connect to genuinely independent feeds. Two switches protect a server only if its interfaces, virtual network and upstream route are configured to use both. Two links to one carrier may survive a patch-panel problem but not the carrier's commercial suspension or a shared router failure. A second carrier in the same building may still share the external fibre entrance.

RFC 4116 explains why Internet multihoming is useful but not magical: multiple paths can improve session survivability, yet convergence delays, address policy and operational complexity remain. For kCore, a convincing redundancy disclosure would state whether there is a second default-capable upstream; whether circuits leave by separate physical paths; whether edge routers, optics and power are duplicated; and whether the surviving path has enough committed capacity to carry priority traffic. It would also show that failover is exercised rather than merely configured.

The absence of a kCore entry in PeeringDB's AS401197 query adds no proof either way. PeeringDB participation is voluntary, especially for small networks that buy transit rather than seek public peering. By contrast, PeeringDB's AS4213 record describes a much larger network operating across many facilities. That breadth belongs to AS4213. It should not be attributed automatically to kCore. A customer route entering one large upstream does not inherit independent kCore capacity in all of the upstream's sites.

The practical result is straightforward. A failure or contract dispute at the AS4213 handoff is a credible common-mode path for kCore's public routes. Evidence that would reduce this concern includes a second observed upstream, a published failover test, a route collector showing alternate paths, or a contract describing diverse handoffs with enough backup bandwidth. Until then, kCore's dual-stack edge is live and globally visible, but externally it has one way out.

Northern Virginia is the strongest location signal, not a confirmed facility

kCore's network leaves clues about where at least some equipment may operate. The corporate website resolves to 67.198.230.22. RIPEstat's network-information response places that address in 67.198.230.0/24, originated by AS4213 rather than AS401197. Public registry summaries label the encompassing 67.198.230.0/23 as KRYPT-IAD1, using the airport code commonly associated with the Washington Dulles and Northern Virginia market. RIPEstat's commercial geolocation feed places the block in Reston. IPinfo's traceroute to kCore's own IPv4 block reached the target from Ashburn in roughly two milliseconds after the AS4213 network.

Taken together, those observations strongly suggest a Northern Virginia operating point. They do not identify the exact building. IP geolocation can reflect registration, routing policy or a nearby router rather than the server's rack. IAD1 is a provider label, not a contractual statement from kCore. AS4213 operates in numerous US metros, and a route can be handed off remotely. The low latency makes a distant production location less likely for the measured address, but one measurement cannot locate every service or every backup.

This is why the Houston and Northern Virginia signals should not be collapsed. Houston is the legal and contact surface shown in ARIN and the company's terms. Northern Virginia is the best technical signal for the publicly measured infrastructure. A separate legal notice on the site lists another Houston address for copyright correspondence. None of those addresses establishes where customer files, email or backup copies are stored.

The company's terms preserve broad movement rights. Section 4.3 says hardware configurations may vary and kCore may replace host hardware, move an account to another server, or transfer it to another data centre or geographic location when it considers that necessary for service quality and security. Section 15.4 says an account and its backups may be in different data-centre locations, that backups may be stored in another state, country or continent, and that emergency restoration may occur outside the customer's chosen location.

Those clauses may help recovery by allowing the operator to escape failed hardware or a troubled site. They also mean that locality is not fixed merely because the company and ASN are American. A buyer with state, national, contractual or sector restrictions needs a written placement commitment that covers production, backup, temporary recovery, support access and subcontractors. The contract should explain notice and consent when a copy crosses the agreed boundary. Without that commitment, the provider's right to move data is broader than the public infrastructure map.

DNS shows useful separation, but it is not a second hosting region

kCore's domain-service design is more distributed than its public BGP edge. Google Public DNS's A-record response shows the corporate site on the AS4213 address rather than the company's own IPv4 /24. Its NS response delegates the zone to a.ns.cl0secall.net and b.ns.cl0secall.net. At the time of review, the first authoritative server used addresses in AS4213 and AS401197, while the second used addresses in AS25795 and a separate IPv6 network. The MX response likewise placed one mail exchanger in AS401197 and another on the separate network.

That arrangement can provide genuine benefits. If AS401197 disappears, a secondary authoritative server outside that route may continue answering for the domain. An external mail exchanger may queue messages while the primary server is unavailable. Hosting the sales site on the upstream's address space can keep the public page reachable during a route-origin fault affecting the kCore /24. These are sensible separations at the domain and communications layers.

They also create dependencies that should be named. The authoritative hostnames use cl0secall.net, a different domain whose ownership and service terms are not explained on the kCore site. The corporate page remains inside AS4213, the same autonomous system publicly observed as kCore's sole upstream. A route-level AS4213 incident could therefore affect the customer network and the company website even though their addresses belong to different allocations. The second DNS and mail path may survive, but public evidence does not establish how support staff would publish an incident if the customer portal and primary network failed together.

The customer portal links to a network-status page, but an unauthenticated request is redirected to login. The public announcements feed is visible and useful, although it is not a continuously updated status dashboard. The distinction matters during an outage. A customer who cannot authenticate because the portal or identity service is down needs a public, independently hosted source of incident ownership, affected services and restoration updates.

DNS diversity therefore deserves credit but should not be misread as application redundancy. A website can resolve correctly while its database, storage or control panel is unavailable. A secondary mail exchanger can accept a message without restoring the customer's mailbox. A separate status channel can describe a failure without reducing it. Each layer has value; none proves that the underlying shared-hosting workload can move to another production stack.

SSD RAID 10 is installed capacity, not guaranteed usable capacity

kCore's hosting page says the entire platform runs on SSD RAID 10 storage. RAID 10 normally combines mirroring and striping, allowing some drive failures without losing the array and improving performance compared with a single disk. It is a reasonable design choice for shared hosting. It still leaves several questions unanswered: the number and model of drives, controller design, spare policy, rebuild time, monitoring thresholds, filesystem layout, write-cache protection and whether replicas share the same chassis or power domain.

The economics sit behind those details. The listed entry plan costs less than ten dollars a month and includes storage, database space, email, certificate automation, support, monitoring and migration. Low prices are possible because many tenants share servers, software licences, network capacity and staff time. The provider earns a return by keeping utilization high. Resilience requires the opposite margin at crucial moments: unused drive bays, spare servers, free storage, uncommitted rack power and staff time available when several things fail at once.

Installed capacity is the amount physically present. Usable capacity is what can safely be sold while preserving performance, rebuild room and recovery headroom. A server may have abundant nominal disk space but lack enough input/output performance during a RAID rebuild. A rack may have vacant units but no remaining power allocation. A virtual host may accept another account but lack memory to absorb neighbours after one node fails. Public plan limits describe the customer's quota, not the provider's remaining reserve.

kCore's platform page says it uses enterprise-grade server hardware, designs around individual component failures and actively manages equipment life cycles. Those are the correct categories. The page does not publish hardware generations, replacement thresholds, failure rates or an inventory of ready spares. The contract permits hardware configurations to vary. That flexibility supports practical operations, but it prevents a buyer from inferring a standard fleet or guaranteed replacement class.

Repair windows depend on stock and access. If a drive fails, a local spare can be installed quickly; if no compatible drive is on site, procurement and shipping become part of the outage. If a motherboard fails, a whole-system spare can shorten recovery; otherwise the operator may have to transplant disks, restore to different hardware or wait for a part. In leased space, kCore may need facility staff to admit a technician or perform remote hands. A one-hour exclusion in the SLA does not make a one-hour physical replacement possible.

A strong capacity answer would quantify failure reserve without exposing sensitive detail: number of production sites, number of server fault domains, minimum spare-node margin, on-site replacement categories, storage free-space threshold and maximum oversubscription policy. It would disclose whether a single server can fail without moving tenants manually. It would also distinguish backup storage from live redundant storage. RAID keeps a service running through some component failures; it does not create an independent historical copy.

The 99.9% guarantee is narrower than the headline

kCore repeatedly promises 99.9% uptime. On an annual basis, that percentage permits about eight hours and 46 minutes of counted unavailability. The hosting page rounds this to about nine hours a year. For a brochure, that arithmetic is understandable. For an operator deciding whether a website can be offline for an entire business day, the definition of counted downtime matters more than the percentage.

Section 5 of the published terms defines the commitment as network uptime measured annually. The remedy begins with one month of free hosting if total uptime is below 99.9% but above 99%, with another month for each percentage point below 99%. Compensation is limited, and the company's internal records are the sole standard for determining entitlement. The agreement describes this credit as the exclusive remedy for network, software, hardware or equipment failure where law permits.

The exclusions are broad. Scheduled maintenance does not count. Emergency maintenance and hardware or software failures fixed within one hour do not count. Neither do distributed denial-of-service attacks, hacker attacks, downtime caused by reaching plan limits, service changes, periods spent processing technical-support requests, customer configuration, third-party applications, certain notified DNS or address changes, policy violations, force majeure or events beyond the company's control.

These exclusions can make operational sense individually. Maintenance is necessary; customers cause incidents; attacks can overwhelm purchased capacity. Collectively, however, they create a large difference between experienced downtime and credited downtime. Eleven separate 59-minute hardware failures could produce nearly eleven hours of disruption while falling within the under-one-hour exclusion. A customer can be unable to serve traffic during a denial-of-service attack while the event does not reduce the SLA calculation. A support-dependent restoration can remain outside the calculation precisely while the customer is waiting for help.

The guarantee is also about the network, while the sold service is broader. A route may be reachable when the web server returns errors. A web server can run while the database is locked. A control panel can be down while static sites continue serving. Email may be delayed while a website is healthy. A customer needs component-specific service indicators or an end-to-end definition that begins at the visitor's request and includes the application dependencies kCore controls.

The May 2026 emergency-maintenance notice illustrates the distinction. kCore said an urgent security issue required a short customer-portal outage at 10pm Eastern time and later marked the maintenance complete at 10:25pm. This is positive operating evidence: a dated notice, stated reason, completion update and support invitation. It concerned the portal, not necessarily hosted websites. The public record does not show whether the outage counted against any service measure, whether customers retained another management path, or whether a later incident review was issued.

A more decision-useful availability record would publish monthly measurements, incident duration from the customer's viewpoint, service-specific exclusions and the number of tenants affected. It would separate planned work from emergency work and report how often the one-hour exception is used. The current SLA is real enough to price a limited credit. It is not a recovery-time commitment for every layer the customer relies upon.

Backup language makes the customer the last line of recovery

The contract is clearest where the marketing page is least specific. Section 11.20 requires customers to keep copies of all content in a location independent of kCore and says they must not use kCore's backup service as their sole backup. Section 15 says kCore will use commercially reasonable efforts to back up hosting-account data, but a copy may be unavailable because of file count, backup-software failure, storage failure or corruption. It keeps a limited number of copies as stated on the applicable product page and may delete old copies after a plan change.

The public hosting page reviewed here promotes application-level backup and restore features but does not state a retention count for the platform backup. The terms add that a restored copy may arrive as raw data requiring reformatting, and that the customer's remedy after an unsatisfactory restore is to use its own backup. Paid backup creation and restoration are excluded from the money-back policy. This is not an assurance of a particular recovery point or recovery time.

The risks are different. RAID 10 addresses some live disk failures. A backup addresses deletion, corruption, compromise or a need to return to an earlier state. A copy in the same rack can survive a drive failure but not a rack power event. A copy on the same administrative account can survive server loss but not necessarily account takeover. A geographically remote copy can survive a facility incident but may introduce transfer time, locality restrictions and a dependency on the same credentials or provider.

CISA's ransomware guidance recommends offline, encrypted backups and regular restoration tests. The important word is tested. A backup job reporting success proves that bytes were written somewhere; it does not prove that databases are consistent, credentials exist, encryption keys are available, names can be redirected, or the restored site will run on the target stack. A useful test measures the time from declaring failure to serving traffic from the recovered copy.

For kCore customers, the independent copy should include website files, database dumps, mail if it matters, DNS records, certificate and key material where appropriate, account configuration, scheduled jobs and documentation of the software versions required to run the site. The copy should be accessible without the kCore portal. Its restoration destination should be identified before an incident, not after the shared server is unavailable.

kCore could strengthen the evidence by publishing retention periods, copy frequency, storage separation, encryption practice, restoration priority and historical restore success. It could define a recovery-point objective and recovery-time objective per plan. At present, the contract sensibly tells customers not to delegate their last copy to the provider. Buyers should take that warning literally.

Migration into kCore is described; migration out remains a customer exercise

The migration page offers a simple inbound sequence: buy hosting, optionally transfer the domain, open a concierge ticket and let the team migrate the website. The hosting page says experts will move website data from the old provider with little or no downtime. For a small site, hands-on migration help may be more valuable than a sophisticated self-service tool.

Inbound assistance does not establish exit portability. The public material does not define which source control panels, database versions, mailbox formats, scheduled tasks or application stacks are supported. It does not promise a full account export, maximum export time, egress bandwidth or help moving to a competing provider. The only public shell-access article says customers can request shell access for shared or WordPress hosting through a support ticket. That may make file transfer easier, but it does not specify privilege level, duration or access during account suspension.

NIST's Cloud Computing Standards Roadmap treats portability as the ability to move data or applications and highlights differences in interfaces, formats and virtual-machine technologies as sources of lock-in. Shared hosting is simpler than moving a complex virtual estate, but the same principle applies. Files are only one part of a functioning service. Database encoding, mailboxes, DNS timing, certificates, PHP extensions, file permissions, background jobs and application secrets must arrive in a usable state.

The contract also creates exit pressure around billing. Fees are due in advance. Failed payment may lead to suspension or termination, and kCore disclaims responsibility for content lost as a result. Automatic renewal can fail even when enabled, and the customer remains responsible for ensuring payment. Services can terminate at expiry. During a billing dispute, a chargeback may lead to suspension until outstanding amounts are paid.

This is not unusual in low-cost hosting, but it turns billing into an infrastructure dependency. An expired card can become a data-availability event. A customer whose only fresh copy sits behind the provider's login may discover that the time to prepare an export was before the invoice dispute. The remedy is operational: maintain more than one current payment contact, monitor renewal confirmations, keep independent copies and test restoration elsewhere.

A mature exit statement would specify how long data remains available after cancellation, suspension or expiry; whether exports remain possible during a dispute; the formats supplied; expected throughput; and the support charge for a managed exit. It would separate domain registration from hosting so the customer understands which names, records and content can move independently. kCore explains how to arrive. Customers still need to engineer how to depart.

Support labour is part of the capacity sold

kCore differentiates itself with human support. The concierge page says its technicians are knowledgeable and not outsourced to a large generic support centre. It offers one-to-one technical guidance and limited consulting for an hourly fee. The platform page claims continuous monitoring and complete on-call response coverage. The hosting plans include ticket support, and the site publishes phone and email contacts.

Small-team support can be excellent because the person answering may understand the entire environment. It can also concentrate knowledge and authorization. ARIN lists one named individual across administrative, technical, routing, DNS, network-operations and abuse roles for the company's resources. That does not prove there is only one operator; registry contacts are often deliberately consolidated. The company does not publish a staff count, shift model, escalation ladder, response targets or succession arrangements.

Contract language narrows the promise. Technical support is provided as available, and kCore does not guarantee that every inquiry will be handled within advertised statistical averages. It may have full access to services and content while assisting. Customers are told to back up before requesting help because changes may affect website function. Requests outside the included scope can require advance payment, and support may be refused in several circumstances.

Repair therefore has a human queue. A monitoring alert must reach someone who can diagnose the right layer. That person may need facility access, an upstream ticket, a spare part, a vendor licence or customer approval. If several tenants fail with the same server, one expert may be efficient because the cause is shared. If a facility or security incident produces many distinct tasks, the same small team can become the limiting resource.

The May 2026 portal notice shows at least one rapid, direct communication cycle and a completion update. It does not measure response to a midnight storage failure or a widespread route outage. The publicly linked network-status surface requires authentication, so prospective customers cannot inspect historical uptime or incidents. The announcement archive contains little public history. Absence of reports is not proof of absence of incidents; it is absence of a public record from which outsiders can calculate performance.

Buyers should ask for severity definitions, first-response targets, restoration ownership and a path that remains reachable when the portal is unavailable. They should identify who can authorize emergency DNS changes and data release. For business-critical service, support capacity belongs in the architecture just as surely as disk and transit do.

Failure travels through tenants, domains and communications

A shared-hosting failure rarely affects only a server owner. One physical host may carry many unrelated websites, databases and mailboxes. A storage problem can take several customers offline at once. A compromised control panel can expose domains and accounts. A DNS failure can make healthy content unreachable. A billing or domain-renewal failure can interrupt a site without any broken hardware.

kCore's small visible address footprint makes this aggregation important. IPinfo's hosted-domain estimate is too incomplete to count customers, and a shared IP can front many names. The evidence needed to establish exposure is a provider-supplied tenant distribution: not customer identities, but the maximum number of accounts per fault domain, percentage of customers on the largest server, and whether mail, DNS and control services share that domain.

The domain product adds another dependency chain. kCore says it resells domain names through a registrar partner. The domain page lets customers manage nameservers, registrar locks and contact information in the same customer environment. Bundling simplifies administration and billing. It also means that a compromised account or failed renewal can touch both the content and the name used to reach it. The contract notes that domain transfers and registrations remain subject to registry and registrar rules.

Customers can reduce that blast radius by separating ownership credentials, requiring multifactor authentication, preserving DNS records elsewhere and deciding whether domain registration should remain with an independent registrar. kCore's terms require two-factor authentication for the user area, which is a useful control. Account recovery still needs an independent contact method and a documented proof-of-ownership process.

Service suitability also has boundaries. The terms say the service is not HIPAA compliant and prohibit protected health information. High-risk uses require prior confirmation and independent redundant systems. These exclusions help prevent a small shared-hosting platform from being mistaken for infrastructure designed for life safety or regulated health data. They do not answer every locality or privacy question for ordinary customer data.

When kCore fails, the most directly affected parties are website owners, their visitors, mailbox users and anyone relying on a hosted domain. Secondary effects can include lost sales, missed messages, expired authentication links, inaccessible community information and delayed incident coordination. The cheap monthly invoice can therefore sit upstream of activities worth much more than the hosting fee. The SLA credit is unlikely to match that external cost, which is why independent recovery matters.

What would demonstrate resilience rather than merely describe it

kCore has enough public evidence to avoid a negative operating assessment. Its order surface is live. Its routes are current and widely visible. It has directly allocated address space, dual-stack announcements, functioning authoritative and mail services, a documented contract, active support channels and a dated 2026 maintenance communication. Those are substantive signals for a small provider.

The next evidence should be operational and narrowly scoped. First, identify the production metro and legal facility operator, while allowing sensitive rack detail to remain private. State whether a second active production site exists and which services can run there. Distinguish backup location from failover capacity. A remote copy is valuable, but it is not a ready application platform unless compute, software, credentials, DNS and network capacity are also prepared.

Second, document network failure domains. Name the number of upstream providers, edge routers and physical handoffs; disclose whether links use separate entrances and power; and publish the date and outcome of a failover exercise. Add a valid route-origin authorization for the IPv4 /24. The IPv6 authorization shows the company already understands the mechanism.

Third, disclose usable-capacity controls. A buyer does not need serial numbers. It needs to know that the largest server can fail without overloading survivors, that compatible replacements are on site or contractually available, and that storage rebuilds preserve performance. State the reserved headroom and the replacement target for drives, servers and network devices.

Fourth, turn backup language into measurable recovery. Publish frequency, retention, separation, restore priority and tested recovery ranges. Offer a customer-readable export procedure that does not depend on a healthy portal. Clarify data location for production, backups and emergency restoration, especially when a customer pays for US placement.

Fifth, make incident evidence public. An independently hosted status page with component history would let customers distinguish website, portal, DNS, mail and hosting failures. Post concise incident reviews for material events and report both experienced and SLA-counted downtime. This would make the 99.9% number auditable without revealing customer information.

Finally, describe support escalation. Publish severity levels, acknowledgement targets, after-hours channels and who can authorize facility work or an emergency migration. A small company does not need to imitate a hyperscaler. It does need to show that one unavailable person, one failed payment processor or one overloaded ticket queue cannot indefinitely block restoration.

The operating verdict is real but deliberately limited

kCore Cloud is operating. The current evidence is stronger than a thin directory description might suggest: AS401197 has sustained dual-stack routing, the company acquired its own IPv4 space, the commercial site and portal are active, and a 2026 security-maintenance notice shows someone tending the service. The company's own language also sets a useful expectation by emphasizing small scale and owned hardware rather than pretending to be a global utility.

The same evidence defines the limit. One externally observed upstream carries both route families. The physical site is not publicly identified. Northern Virginia is the strongest inference, not a confirmed customer commitment. The amount of installed hardware and remaining failover capacity is unknown. The SLA excludes many real outage experiences. Backup restoration is not guaranteed, independent copies are the customer's responsibility, and data may move across state or national boundaries. Public incident history and support escalation remain sparse.

For a modest website whose owner keeps a tested external copy and can tolerate hours of disruption, that risk may be acceptable at the published price. For a service that must remain available through a carrier failure, hardware shortage, account dispute or facility evacuation, the public evidence is limited public evidence. The customer would need contractual placement, diverse transit, quantified recovery capacity, export rights and an independent restoration destination.

That is the central hosting-economics bargain. kCore combines racks, licences, transit and human expertise so customers do not have to buy them separately. The low monthly fee works because those resources are shared. Resilience works only when some of them are not fully consumed, when failure domains are genuinely separate, and when a repair can occur before the customer exhausts its tolerance. kCore has shown a live service and a credible small network. It has not yet shown, in public, the spare system that would carry that service when the visible one breaks.