La promesse de 99,9 % de TECNOWEB Colombia rencontre une clause de réparation de 48 heures dans une installation anonyme

Résumé

• La garantie d'hébergement annuelle de 99,9 % de TECNOWEB Colombia autorise environ 8 heures 46 minutes d'indisponibilité, mais ses conditions accordent à l'équipe technique jusqu'à 48 heures après notification pour résoudre un incident éligible et ne publient pas de méthode de mesure, de barème de crédit de service ou d'objectif de reprise par produit.
• L'entreprise déclare posséder ses serveurs, utiliser des armoires exclusives, des consoles à distance et une gestion de l'alimentation à distance, et envoyer des copies incrémentielles vers un centre de données externe, mais elle ne nomme pas publiquement les installations de production ou de sauvegarde, n'identifie pas leurs juridictions et ne montre pas quelle capacité reste utilisable après une panne d'hôte, d'alimentation, de refroidissement ou de réseau.
• AS64114 et les blocs d'adresses enregistrés en Colombie constituent une preuve publique active d'une empreinte réseau réelle, tandis que deux fournisseurs en amont observés et plusieurs présences sur des points d'échange ne sont que des connexions logiques; ils n'établissent pas que les racks de TECNOWEB Colombia disposent de deux sorties physiques indépendantes, de deux chemins d'alimentation indépendants ou d'une destination de migration testée.

Huit heures de marge, suivies d'une horloge de 48 heures

L'arithmétique derrière 99,9 % est assez simple pour tenir sur une facture. Sur une année de 365 jours, les 0,1 % manquants équivalent à 525,6 minutes: 8 heures, 45 minutes et 36 secondes. C'est la totalité de la marge d'interruption annuelle si chaque minute d'indisponibilité est comptée. Pour une entreprise dont le site web, la caisse, l'application ou la boîte mail est hébergé sur le service, la question importante n'est pas de savoir si trois neufs semblent rassurants. C'est de savoir quand le chronomètre démarre, ce qui l'arrête, quelles pannes comptent et ce qui se passe lorsque la marge est dépassée.

Lapage d'accueil colombiennede TECNOWEB fait la promotion d'une disponibilité de 99,9 %, d'une activation immédiate, d'un support en espagnol 24h/24 et 7j/7, de sauvegardes automatiques et d'un hébergement dans des centres de données « de premier niveau ». Lesconditions de serviceactuelles sont plus conséquentes. Elles indiquent que TECNOWEB Colombia SAS garantit une disponibilité annuelle de 99,9 % pour les services d'hébergement. Pour un incident hors cas de force majeure, l'équipe technique fournira une solution dans un délai maximum de 48 heures à compter de la notification. Le même document exclut ou limite la responsabilité pour les interruptions attribuées aux distributeurs d'électricité, aux catastrophes naturelles, aux liaisons nationales ou internationales fournies par des tiers, au matériel ou logiciel tiers, et à une mauvaise gestion des identifiants.

Ces déclarations peuvent coexister contractuellement, mais elles laissent un large écart opérationnel. Une fenêtre de résolution de 48 heures est plus de cinq fois la totalité de la marge d'indisponibilité annuelle. « Solution » peut couvrir une réparation, une solution de contournement, une copie restaurée ou une autre réponse; les conditions ne la définissent pas. Elles ne disent pas non plus si la disponibilité est mesurée au niveau d'un serveur, d'un port d'application, d'un panneau de contrôle, d'un domaine client ou de la périphérie du réseau de TECNOWEB.

Il n'existe pas de formule publique pour la maintenance planifiée, la dégradation partielle, la perte de paquets ou un client qui ne peut atteindre un serveur que par une seule route défaillante. Il n'y a pas non plus de tableau de crédits de service publié qui traduise la disponibilité manquée en compensation.

Ce n'est pas une preuve que TECNOWEB a connu une panne de 48 heures, ou que sa restauration normale prend autant de temps. C'est une preuve que le contrat public et le chiffre marketing répondent à des questions différentes. Le chiffre marketing décrit un résultat. La clause décrit le temps maximal autorisé pour agir après qu'un client a signalé un problème.

Une évaluation sérieuse de la continuité a besoin du pont opérationnel entre les deux: une surveillance qui détecte un incident avant un ticket, des niveaux de gravité nommés, des intervalles d'accusé de réception et de mise à jour, un objectif de restauration, un objectif de récupération des données et un enregistrement de si le résultat a été atteint.

TECNOWEB's VPS page also invokes “Tier III.” TheUptime Institute explanation of Tier classificationsdefines Tier III as concurrently maintainable, with redundant components and distribution paths that permit planned maintenance without shutting down IT operations. TECNOWEB's public page does not name a facility, link a certificate or state which room and load the designation covers. The prudent reading is therefore a vendor claim about the hosting environment, not independently scoped proof that every product, rack and dependency inherits Tier III characteristics.

The promise becomes meaningful only at a boundary. If a power event takes one host down and a virtual machine restarts elsewhere in minutes, the year may remain within 99.9%. If the healthy host lacks RAM, storage or licensed capacity, migration stalls. If the server survives but both visible upstreams share one building entrance, traffic still stops. If a backup exists but cannot be restored quickly, data protection does not restore availability. The remaining ten sections follow that chain from contract to rack and back to the customer.

The catalogue is broader than one hosting stack

TECNOWEB Colombia is not selling a single uniform machine. Its current catalogue spans shared environments, virtual machines, physical servers, reseller accounts, managed mail, third-party productivity suites, domain registration and security services. Each product moves the operating boundary and changes what a customer can reasonably expect TECNOWEB to control.

TheLinux hosting pagemarkets cPanel, LiteSpeed and NVMe storage. It assigns finite storage and mailbox quotas to four plans and distinguishes weekly backups on the smaller offers from daily backups on the larger ones. TheWordPress offeradds an optimized application layer, cache and a WordPress management interface.Windows hostingshifts the customer to Plesk, IIS and Microsoft-oriented application support, while theJava serviceadds Tomcat and Java runtime dependencies. These are not merely different labels. They involve different control planes, patch cycles, licence dependencies, memory profiles and recovery procedures.

Thereseller plansextend the consequence of one infrastructure fault to another company’s customers. TECNOWEB markets WHM, white-label accounts, nominally unlimited domains, clients and transfer, and finite storage tiers from 20 GB to 100 GB. A reseller may present itself as the immediate provider even though the physical repair, hypervisor, storage and upstream path remain outside its control. One failed shared node can therefore reach end users who have never heard of TECNOWEB.

TheVPS catalogueuses KVM on Proxmox and sells plans ranging from two vCPUs, 2 GB of RAM, 40 GB of SSD and 1 TB of transfer to four vCPUs, 8 GB of RAM, 300 GB of SSD and 10 TB of transfer. Customers receive root access, a browser console, snapshots and hypervisor-level firewall controls. Thededicated-server pagepromises exclusive hardware, describes rapid delivery for popular configurations and recommends an additional disk for backup. A dedicated customer avoids noisy neighbours at the guest level, but still shares facility power, cooling, upstream links, remote hands and possibly a top-of-rack switch.

Mail introduces two more boundaries.Email Empresasis presented as an Open-Xchange service with 25 GB of mail storage and 5 GB of file storage per account, collaboration features and 99.9% availability. The olderEmail Pymes pageadvertises 5 GB per account and makes broader claims about backup, redundancy and network availability. TECNOWEB also resellsGoogle WorkspaceandMicrosoft 365. In those products, TECNOWEB can control sale, onboarding, billing and first-line support, but the global application and storage infrastructure belongs to the upstream platform provider.

This range matters because “TECNOWEB is down” can describe several distinct incidents. A shared web node may fail while Google-hosted mail continues. The customer portal may be unavailable while an existing VPS keeps serving traffic. A domain renewal error can remove a working site from the public internet without any server fault. A reseller can lose administrative access while downstream sites remain online. A useful service commitment has to identify the product and the point being measured; a brand-wide percentage cannot by itself describe all of these states.

A Colombian contract sits inside a regional operating boundary

The legal counterparty is visible. AColombian business-directory page drawing on RUES datalists TECNOWEB COLOMBIA S A S as active, gives NIT 901182036, places it in Bogotá and classifies its activities as data processing, hosting and related work, plus IT consulting and administration of computing facilities. TECNOWEB’sColombia payment pageshows the local commercial surface in Colombian pesos and local payment channels. The service terms choose Colombian law and courts in Bogotá.

That does not mean every server, employee, licence or network resource belongs to the Colombian company. The brand’s own “about” material says it has provided hosting-related services since 2002, while the public business listing identifies the present Colombian SAS. Brand history and the age of one legal entité are not the same thing. The website also offers country-specific storefronts across the region. A buyer needs to know which company invoices the service, which company operates the equipment, which company holds the network resource and which entité is responsible when service crosses a border.

The regional boundary is especially clear in internet-number records. LACNIC’s2025 electoral rolllists TECNOWEB COLOMBIA SAS among Colombian organisations. Yet theLACNIC record for AS64114identifies the autonomous system’s registrant as TECNOWEB PERU SAC and records it as active. The separateLACNIC entité entry for TECNOWEB COLOMBIA SASgives a Bogotá administrative address and connects the Colombian organisation to number-resource records.

These entries establish formal identities; they do not establish a parent company, ownership percentage or internal service agreement. It would be an overreach to convert a shared brand, a technical contact or a common autonomous system into a legally proven corporate relationship. What the evidence does show is operational interdependence: Colombian address space can be originated through an autonomous system registered to a Peruvian company, and the technical contact can administer resources across multiple country labels.

The customer-facing Colombian company may therefore rely on group or partner capabilities that are not described in the retail contract.

This distinction matters in recovery. Suppose a Colombian customer’s address remains registered to TECNOWEB Colombia while route changes are made under AS64114. The staff authorized to alter routing may work for another regional entité or a shared operations function. Suppose the production rack is in a facility contracted by a sister company. The Colombian seller may coordinate support but not control building access or carrier dispatch. None of these arrangements is inherently weak; regional hosting businesses commonly share infrastructure. The risk comes from opacity about authority and escalation when minutes matter.

A robust customer schedule would name the contracting entité, infrastructure operator, facility operator, network operator and material subcontractors. It would also say which party can authorize a route change, move a virtual machine, retrieve an off-site copy, replace a disk and communicate an incident. The public pages name products and a Colombian counterparty. They do not publish that responsibility matrix.

The company describes its racks without naming the building

TECNOWEB’scompany pagesupplies unusually concrete first-party descriptions. It says the company owns rather than rents all its equipment and servers; uses dual Intel Xeon systems with 128 GB to 256 GB of RAM, enterprise SSDs and RAID 1 or RAID 10; equips servers with 10 Gbps optical network cards; houses them in exclusive cabinets; and attaches remote console and remote power-management devices. It also claims three firewall layers, monitoring around the clock, DNS in Chile, the United States, France and England, and daily incremental copies sent to an external data centre.

Those are useful statements about an intended operating design. They describe control at the server and cabinet level: owned hardware, restricted physical access, out-of-band administration and the ability to cycle power remotely. They also reveal dependencies. A remote console works only while its management network and authentication service are reachable. A remote power unit can restart a locked server but cannot repair a failed power supply, replace a disk or restore a dead switch. RAID can tolerate specified disk failures; it is not a copy protected from deletion, corruption, fire or a storage controller fault.

The missing noun is the facility. The page repeatedly says “the centres de données” or “an external centres de données” without naming either one. It does not give a street address, facility operator, room identifier, certification number, power topology, cooling topology, fire-suppression design, flood exposure, carrier entrances or backup-site jurisdiction. The VPS page calls the environment Tier III, and the dedicated page speaks of servers in Colombia and a range of data-centre options, but neither provides a facility-specific record that binds those descriptions to the Colombian plans available on the research date.

The Bogotá address in LACNIC’s entité record is administrative evidence, not a data-centre coordinate. A network-resource holder can be registered at an office while its servers operate in another city or country. Likewise, nationwide sales to Bogotá, Medellín, Cali and other cities describe a market, not the location of the racks. Hosting reaches a Colombian customer over the internet; it does not need a server in the customer’s city.

One address-level observation makes the location question sharper without resolving it.IPinfo’s page for 179.61.15.3, an address inside a block registered to TECNOWEB Colombia, places that address in Tampa, Florida and labels it hosting infrastructure. The page itself is an observational geolocation product, not a facility contract. One IP can be moved, remotely announced, inaccurately located or used for only one service. It cannot prove where the shared-hosting fleet, VPS hosts, dedicated servers or backup copies reside.

The correct conclusion is not “the servers are in Tampa.” It is that country labels in address registration, website storefronts and geolocation databases answer different questions. Legal holder location, customer market, route origin and physical rack location can diverge. The evidence that would settle the matter is straightforward: a current facility schedule naming the production and backup buildings, their operators and countries; a product-to-site allocation; a certificate or audit scope where claimed; and confirmation that customer data is stored or replicated only in the stated places.

Until that evidence is available, the physical surface can be described but not mapped precisely. There are servers, cabinets, network interfaces, remote-control devices and backup systems according to the company. There is active address space and routing. There is a Colombian office and contract. There is not a publicly verifiable chain joining a particular Colombian plan to a named rack in a named facility.

Sold quotas do not reveal installed or survivable capacity

Hosting pages are rich in customer quotas and nearly silent about total plant. That is normal in retail hosting, but it makes capacity analysis easy to get wrong. A 50 GB plan is not evidence that a provider installed only 50 GB, and 1 TB of transfer is not a 1 Tbps port. The figures describe what one customer may consume under a product, not how much server, storage, network or power capacity the provider has installed.

The Linux plans publish 10 GB, 30 GB, 50 GB and 80 GB of NVMe storage, with differing mailbox, database, domain and backup entitlements. The reseller page publishes 20 GB, 30 GB, 50 GB and 100 GB while using “unlimited” for domains, clients and transfer. Unlimited cannot mean physically infinite; it is a commercial promise bounded by shared hardware, acceptable-use rules and the provider’s ability to control contention. The pages do not disclose the number of accounts per server, storage oversubscription, CPU limits, memory limits, I/O thresholds or the spare node capacity reserved for evacuating a failed host.

The VPS page is more explicit at the guest boundary. Its four plans show vCPU, RAM, SSD and transfer allocations and assert that resources are dedicated without overselling. Even if every listed guest allocation is enforced, physical headroom remains unknown. Four 8 GB guests can fit on many different hosts; a cluster with one spare node behaves differently from a single fully committed server. KVM isolation does not disclose the number of hosts, the placement policy, shared storage design, live-migration capability, licence availability or how many guests can restart after the largest host fails.

The company page’s 128 GB to 256 GB server-memory range and 10 Gbps network-card claim are installed-component signals, but there is no server count or date-specific inventory. A network interface rated at 10 Gbps is not evidence of 10 Gbps of paid transit, switching backplane, sustained throughput or usable bandwidth during an upstream failure. RAID 1 and RAID 10 describe disk layout, not available storage after reserve, snapshots and backups.

The dedicated-server page’s promise of delivery in as little as four hours for popular configurations suggests some inventory or rapid provisioning access, but it does not identify how many units are on hand, where they are held or what happens during a regional hardware shortage.

Email capacity is similarly segmented. Email Empresas assigns 30 GB per account across mail and files; Email Pymes assigns 5 GB. Google Workspace and Microsoft 365 offers expose licence and mailbox entitlements supplied by their platform owners. TECNOWEB can sell more accounts without adding a server to its own rack when the upstream vendor carries the workload. Conversely, an Open-Xchange service operated on TECNOWEB-controlled or contracted infrastructure may depend directly on its storage and mail cluster. The catalogue does not publish the division.

Capacity therefore needs at least six labels. Design capacity is what an architecture intends. Installed capacity is physically present. Powered capacity can be energized. Operational capacity has been commissioned and is serviceable. Sold or reserved capacity is already committed. Usable capacity is what remains after overhead and reserve. Failure-state usable capacity is the portion that survives the relevant failed host, power path, storage system or network exit.

The public evidence supports individual product entitlements and some component descriptions. It does not disclose total installed compute, total installed storage, paid transit, current utilization, sold capacity, reserved recovery headroom or failure-state usable capacity. No responsible estimate of customer count or fleet size can be derived from the plans. A buyer should ask for evidence at the scale of its workload: the host or cluster placement, current reserve policy, largest-failure assumption and the capacity available after that failure. A headline hardware rating matters only when connected to those states.

AS64114 shows reachability, not a pair of independent fibre routes

TECNOWEB has more network evidence than many small hosting brands. LACNIC records connect Colombian resources to the company, and public route collectors see AS64114 originating a multi-country set of prefixes. That is solid evidence of an active logical network. It is not a map of the fibre between a Colombian rack and the rest of the internet.

TheLACNIC lookup for 45.191.2.0/24returns the enclosing 45.191.0.0/22 allocation and a registrant handle for TECNOWEB Colombia. The179.61.15.0/24 recordidentifies an active reallocated block associated with the same Colombian entité handle. These are number-resource records. They establish delegated address space and administrative responsibility, not the building where every address is used.

BGP.tools’ AS64114 viewobserved 15 IPv4 and 33 IPv6 originated prefixes, including 45.191.2.0/24 and 179.61.15.0/24 under Colombian labels. It also observed two upstreams, Hivelocity’s AS29802 and NetActuate’s AS36236, and several internet-exchange presences.IPinfo’s AS64114 viewlikewise listed those two upstreams and thousands of hosted domains across hundreds of observed addresses. The agreement between two observation services strengthens the case that AS64114 is active and multi-homed at the autonomous-system level on the research date.

It does not establish route independence for a particular Colombian service. One autonomous system can announce different prefixes from different continents. The two upstreams can be present in one site, separate sites, remote exchanges or a mix. Both can enter a building through the same duct, depend on the same metro carrier or terminate on the same router and power feed. Exchange participation in Europe or through virtual connections says nothing by itself about the path used by 45.191.2.0/24 from a Colombian customer.

The distinction is visible in IPinfo’s45.191.2.0/24 page. It labels the resource Colombia but explicitly explains that the country shown is where the resource holder is legally based and may not be where the addresses are used. That warning should govern the whole map. The Tampa signal for 179.61.15.3 is relevant because it suggests at least some Colombia-registered space may be served in the United States. It cannot locate the whole /24 or the rest of TECNOWEB’s products.

The hosted-domain count is also a market signal, not a customer census. Many domains can share one customer, one address can host hundreds of domains, and a domain can be dormant or proxied. The count suggests that the network carries material public hosting activity. It cannot establish revenue, active accounts, Colombian users, rack occupancy or how many people would be affected by one failure.

The failure test must operate at the prefix and facility level. For each production prefix, a buyer should ask which routers originate it, in which buildings, through which contracted carriers and physical entrances. It should ask whether the second upstream remains reachable after removing the first router, first cross-connect, first meet-me room, first duct and first metro provider. It should also ask whether outbound and inbound traffic both fail over, how route security is maintained, and how much bandwidth remains on the surviving path.

Public BGP can verify that a route is seen. A traceroute can reveal one observed path at one moment. Neither can prove underground separation. The absent evidence is a current physical route diagram, carrier letters identifying common infrastructure, diverse building entries, router and power separation, and a test in which the primary path is removed under load. Without that, “two upstreams” is a useful resilience hypothesis, not a demonstrated recovery path.

Backup language changes as the product changes

Backups are where TECNOWEB’s public descriptions become most instructive. They do not form one universal promise. They form several product-specific promises that can protect against different failures and carry different customer responsibilities.

The service terms provide the controlling caution. Automatic copies exist only for plans that expressly include them. Unmanaged VPS, dedicated servers and basic email plans may not include automatic backup. Even where backup is included, the terms call it complementary and tell customers to maintain independent copies. The company disclaims responsibility for data loss arising from third-party software, hardware or manufacturers. That language makes a clean distinction between a hosting service and a customer’s own continuity plan.

The company page makes the broadest infrastructure claim: daily incremental backup through a commercial system to an external data centre in another physical place. The reseller page adds detail, saying daily, weekly and monthly copies of reseller accounts are transferred daily to an external data centre. The Linux page narrows frequency by plan, with weekly copies on the two smaller plans and daily copies on the two larger plans.

These statements can all be true if they describe different products or retention levels, but the public pages do not name the external site, its country, operator, distance, storage isolation, encryption, retention or restoration performance.

The VPS page says manual snapshots are included, automated snapshots can be scheduled and external backup has an additional cost. A snapshot stored on the same storage system or in the same facility is valuable for reversing a configuration error; it may not survive loss of the storage array, credentials, account or building. An external copy may survive the site but still be unusable if the backup network, encryption keys, catalogue or restore host shares the same failure. The page does not publish these boundaries.

The dedicated-server page recommends buying an additional disk and having technicians configure it for copies. A second disk can protect against failure of the primary disk. If it is inside the same chassis, it does not protect against controller failure, power damage, theft, fire or a destructive action that reaches both devices. It is therefore a local recovery component, not proof of site-level disaster recovery.

Email adds another inconsistency in scope. The newer enterprise-mail page advertises 99.9% availability on an Open-Xchange platform. The older SME page uses stronger phrases about zero data loss, backup and 100% network availability. The service terms, however, say basic email may lack automatic backup unless expressly stated. A customer should rely on the order and product schedule that identifies its actual plan, not combine the strongest sentence from each marketing page.

A useful backup commitment has four numbers and three boundaries. The numbers are backup frequency, retention, recovery-point objective and recovery-time objective. The boundaries are the production failure it is designed to survive, the administrative credentials or account separating it from production, and the physical jurisdiction in which the copy resides. TECNOWEB’s public material gives fragments—daily, weekly, monthly, incremental, external—but not the complete combination for each product.

The recovery path also needs capacity. Restoring a 300 GB VPS requires clean storage and compute on which to run it. Rebuilding a dedicated server requires compatible hardware, licences and staff. Moving shared accounts requires spare nodes, DNS changes and control-panel access. A copy can be intact while the service remains unavailable because the destination is full or the network is down. Installed backup storage and usable recovery capacity are not the same.

The evidence needed to close this gap is practical: a product-specific backup schedule, named backup region, proof of separate credentials, recent restore-test results, measured restore speed and confirmation that destination compute is reserved. The most important test starts with a destroyed production instance and ends when a customer can use the application and verify data—not when a backup job reports success.

The control panel and support desk are infrastructure too

For many customers, the retail control panel is the only visible infrastructure. It provisions a service, exposes billing, opens tickets, changes DNS, creates mailboxes, restarts a virtual machine and presents backup controls. When it fails, the underlying server may still run, but the customer’s ability to diagnose or recover can disappear.

TECNOWEB operates a publicsupport portalthat accepts tickets and lets a user check ticket status. Its pages promise 24/7 assistance, while the terms say support is available through the client portal. The public material does not state whether there is a separate emergency telephone path when the portal or customer authentication system is unavailable, or whether the support interface is hosted outside the production estate it supports. That is a common-mode question: a status page and ticket system are most useful when they survive the incident.

Different services add different administrative surfaces. Linux customers depend on cPanel; reseller customers use WHM; Windows customers use Plesk; VPS customers use Proxmox-based controls and noVNC; WordPress customers use an application toolkit. A control-plane fault can block password resets, snapshots, reinstalls, firewall changes and migrations without making every hosted application unreachable. Availability reporting should distinguish customer traffic from administrative access.

The dependency chain extends beyond hosting. TECNOWEB’sdomain pagesells registration and DNS-related services while the terms describe the company as an intermediary before registries. A valid server can vanish from ordinary use if a domain expires, delegation changes or authoritative DNS fails.SSL certificatesadd certificate authorities and renewal automation.SiteLockadds an external security service. TheDMARC offeris presented around Valimail, andBIMI certificatesrely on brand-verification and certificate ecosystems. None of those dependencies is repaired by replacing a failed server disk.

The Google and Microsoft offers make the division of responsibility clearer still. TECNOWEB can help configure, transfer and support a subscription, but it cannot independently restore a global Gmail, Exchange Online, Teams or OneDrive service. Conversely, an outage in TECNOWEB’s own portal should not necessarily take those upstream platforms down. A customer buying “one provider, one support” needs an escalation path that survives the boundaries between seller, platform operator, registry, certificate authority and network carrier.

Human labour is the final control plane. A remote power cycle is quick; diagnosing a corrupt filesystem, failed RAID controller or compromised account is not. A physical replacement requires a technician with access, a compatible part and authority to act. A route change requires network staff. A restore requires someone who understands the workload and can validate it. A 24/7 label says when a channel is open, not how many qualified people are available, how incidents are prioritized or how long a part takes to reach the rack.

The 48-hour clause makes those operating details central. Buyers should ask for severity definitions, acknowledgment targets, escalation contacts, update intervals, remote-hands availability, spare-part policy and an alternative channel outside the normal portal. They should also ask whether monitoring opens incidents automatically. A guarantee measured only after customer notification can lose precious minutes or hours before the provider’s formal clock begins.

One failure can reach businesses that never bought a server

The people affected by a hosting failure are wider than the account list. A shared-hosting customer may be a small retailer whose checkout and business email use the same domain. A VPS may run an enterprise resource-planning system, database, booking service or application interface. A dedicated server can carry several business units. A reseller can place dozens of downstream organisations on one allocation. An agency can manage sites for clients who have no direct relationship with the infrastructure provider.

TECNOWEB’s catalogue explicitly targets individuals, small and medium-sized businesses, large companies, ecommerce, databases, enterprise applications and resellers. Its home page claims more than 10,000 Colombian customers and more than 20,000 managed domains. Those are first-party marketing figures without an accompanying dated customer definition or audit. IPinfo’s lower observed-domain count concerns domains seen on AS64114 addresses, not all customers, all products or all domains under management. The two figures measure different things and should not be forced into agreement.

The impact mechanism also changes by layer. Loss of one shared server affects accounts placed on it, not necessarily the fleet. Loss of a storage system can affect several hosts. Loss of a top-of-rack switch can isolate one cabinet. Loss of facility power or cooling can affect the room. Loss of a common upstream route can affect otherwise healthy servers. Loss of DNS can make many separate applications appear down. Loss of the support portal can delay recovery across products.

Customers carry part of that impact. An unmanaged VPS owner controls the operating system and application. A reseller controls downstream communication. A domain holder must maintain registration data and renewal. A business must decide whether to keep an independent copy and a secondary service. TECNOWEB’s terms make several of these duties explicit. But customer responsibility does not remove the provider’s obligation to make its own boundaries intelligible.

No public evidence supports a precise number of users who would be affected by a rack, prefix or facility failure. Domain counts are not users; advertised customers are not concurrent workloads; address space is not occupancy. The sound assessment is qualitative: the service surface is broad, resellers amplify dependencies, and small businesses may concentrate web, mail, DNS and support with one brand. That concentration can turn a local technical fault into a commercial outage even when the underlying provider is modest in size.

Data locality cannot be inferred from a Colombian storefront

The service contract is Colombian, but the physical and legal path of customer data remains incompletely described. TECNOWEB’sprivacy policysays personal information supplied by users is processed confidentially, used to improve services and not disclosed to third parties without consent except where required by authority. It does not identify hosting countries, backup countries, infrastructure operators, subprocessors, retention periods for hosted content or the locations used by each product.

Colombia’sLaw 1581 of 2012governs personal-data processing and addresses transfers to third countries. The presence of Colombian law does not impose a conclusion here about any particular customer workload. It does make location and role allocation commercially important for customers that store personal data. They need to know whether TECNOWEB acts as a processor, whether another regional company or platform provider participates, and where production and backup copies are handled.

The product catalogue already shows that one answer cannot cover all services. Google Workspace and Microsoft 365 use their respective global platforms. Open-Xchange mail introduces another platform boundary. Domain registration involves registries and registrars. Security products involve their vendors. TECNOWEB-operated shared hosting, VPS and dedicated servers may follow a different location pattern. The terms refer to national and international links and to external manufacturers, while the company page places DNS in four countries and backup in an unnamed external facility.

None of this proves an unlawful transfer or a failure of protection. It proves that a Colombia label is preuves publiques limitées evidence of data residency. LACNIC registration identifies a resource holder; IP geolocation is probabilistic; a billing currency identifies a market; a contract identifies governing law. Only a service schedule, architecture record and subprocessor list can identify where a customer’s content, metadata, logs and copies actually go.

A buyer with locality requirements should ask for production and backup countries, the legal operator in each place, cross-border transfer terms, encryption ownership, access jurisdictions and deletion behavior after cancellation. It should ask whether support personnel in other countries can access data or consoles, and whether a migration changes location. Those answers should be product-specific and incorporated into the contract. A verbal assurance that service is “for Colombia” is not the same as a residency commitment.

The recovery path must be tested from power loss to customer use

A useful resilience test begins with a specific failure. Imagine the power path serving a production cabinet is lost. Stored energy must carry the load while a generator or alternate path becomes available. Cooling must continue. The remote console and power manager must remain reachable. If one server fails, healthy hardware needs enough RAM, CPU, storage, network and licences to accept its workload. If storage is damaged, a clean copy must be available outside the failed domain. If the primary route is lost, a physically independent path must carry the prefix. If the control panel is unavailable, staff need another way to act.

The service is restored only when the customer can use it and verify its data.

TECNOWEB’s public material supports pieces of this sequence: owned servers, RAID, 10 Gbps interfaces, exclusive cabinets, remote controls, monitoring, two observed upstreams, external-copy claims, snapshots, ticket support and a contractual availability percentage. It does not publish a completed end-to-end test that removes a power path, host, storage service or upstream and demonstrates customer recovery under representative load.

The first request should therefore be a named facility schedule. It should identify the production building and backup building, their operators, countries and applicable certifications. It should show which products are placed at each site. If “Tier III” is part of the sale, the customer should receive the current certificate, exact assessed scope and confirmation that its rack, power and cooling paths are within it.

The second request should reconcile capacity. For shared hosting and VPS, buyers need host and cluster architecture, placement rules, committed resources, oversubscription policy and spare capacity after the largest host or storage failure. Dedicated customers need inventory, replacement-part commitments and a migration option. Network evidence should identify paid capacity and the bandwidth available after one upstream is removed. None of these values should be inferred from a NIC rating or retail transfer quota.

The third request should map common-mode dependencies. A physical diagram should show utility inputs, uninterruptible power, generation, cooling, cabinet feeds, routers, carrier entries and outside paths. For network diversity, carrier names are not enough: the paths, entrances, meet-me rooms, routers and power feeds need separation. For backup, “external” should be replaced by a country, facility, credential boundary, retention schedule and measured restoration result.

The fourth request should turn the 99.9% figure into a complete service commitment. It should define the measurement point, interval, exclusions, maintenance treatment, incident start, severity, acknowledgment, update and restoration targets, service credits and termination rights. It should clarify whether the 48-hour language is an outer resolution commitment, what temporary restoration means and how a missed annual threshold is remedied.

The fifth request should test people and communication. Customers should see an after-hours escalation path that does not depend solely on the ordinary portal, a spare-parts policy, remote-hands coverage and a status channel hosted outside the affected systems. A drill should include TECNOWEB, the facility operator, network providers and the customer. It should end with application and data validation, not merely a green infrastructure alarm.

The public record supports an operating Colombian hosting business, a current service catalogue, active number resources and a logical network with more than one observed upstream. It does not support an exact rack location, independent Colombian fibre routes, fleet totals, current spare capacity, a named backup jurisdiction or a measured recovery time. That is why the strongest fact in TECNOWEB’s offer is also the best opening question: 99.9% can be calculated to the second, while the physical system expected to deliver it is still described without a name.