Summary
- StormWeb Canada Hosting Inc. is publicly visible as a long-running Canadian hosting company with a Victoria mailing address, Vancouver server positioning, a CIRA-facing domain-registration offer, shared hosting, VPS, managed dedicated server and cloud-storage products, and published contact points for sales, billing and support.
- The network evidence is stronger than the facility evidence. ARIN records AS14807 for StormWeb Canada Hosting Inc.; PeeringDB lists the network as AS-STORMWEB with a 10G operational VANIX connection; VANIX's entity list and BGP data corroborate the Vancouver exchange presence. None of those records proves data-centre ownership, dual utility feeds, generator runtime, spare server inventory or customer failover.
- The company's own product and contract pages show the real dependency model: services are hosted in Vancouver, plans carry uptime guarantees, shared hosting is constrained by resource and abuse controls, customers must keep their own current backups, scheduled maintenance is excluded from uptime credits, and changes to software, hardware or service providers may affect customer sites.
- Public announcements matter because they describe the operating surface. StormWeb reported a Vancouver core-router maintenance window in 2025, a shared-hosting outage tied to a server-backup snapshot in October 2025, a mail service disruption tied to an automatic software update, and several hardware maintenance windows. These records do not prove a chronic reliability problem, but they show why backup tasks, software changes, rack work and upstream connectivity are the failure paths to test.
- The evidence grade is Medium for identity, service catalogue and network presence, but Weak for facility-level resilience and multi-site recovery. Customers should ask for dated facility, power, transit, backup, restore, support-escalation and data-portability evidence before treating StormWeb's Vancouver-hosted services as a resilient platform for sensitive or time-critical operations.
The company is visible; the plant is not
StormWeb's public identity is not the weak part of the file. Its own about page says the company was founded in 1998, describes it as privately held and 100 percent Canadian owned, and states that it owns and operates an independent network. The same page lists the core offer in plain terms: web and email hosting, domain registration services, virtual private servers, dedicated servers and cloud storage. It also gives the two geographic anchors that matter for an infrastructure reading: the main office is in Victoria, while the servers are situated in Vancouver.
The contact page supplies a specific mailing address at 780 Tolmie Avenue, Building 3, Suite 1032, Victoria, BC, plus a toll-free telephone number and separate billing, support and sales email addresses. That is useful identity evidence. It shows a reachable Canadian company, not only a brand on a price table. The public domain record for stormweb.ca also names StormWeb Canada Hosting Inc. as registrar and registrant contact and points to the same Victoria address. The domain evidence is not facility evidence, but it strengthens the corporate boundary.
The physical plant remains much less visible. StormWeb says "servers are situated in Vancouver"; it does not publish a data-centre address for customer servers, a colocation provider name, a lease term, a rack count, a generator topology, a UPS description, cooling design, power density, or the amount of capacity that is installed, occupied, reserved and available for sale. The company may have these details under contract, and it may reasonably avoid publishing some of them. The point is that public readers cannot convert the Vancouver claim into a resilience claim.
This distinction is important because the article title is about hosted capacity, not just hosting identity. A hosted website, mailbox, VPS, managed server or cloud-storage account depends on a chain of physical and operational resources: a rack, power, cooling, server parts, storage, snapshots, switches, transit, exchange reachability, support staff, account controls, billing state and a route for moving data out if the provider fails the customer's need. StormWeb makes several parts of that chain visible, but the most failure-prone physical layers remain opaque.
The operating-status conclusion should therefore be cautious rather than dismissive. StormWeb has an established web presence, a current product catalogue, a named legal identity, public support channels and a visible autonomous system. It is not a ghost listing. Yet the public file does not let a buyer prove that the advertised service can survive a prolonged utility failure, a Vancouver facility incident, a switch fault, a storage performance collapse, a licensing error, a botched backup snapshot or a staff bottleneck. The company is visible enough to commission; the facility evidence is thin enough to require a downgrade.
Vancouver is the real geography behind the cloud promise
StormWeb sells itself through Canadian locality. The web-hosting page says its plans are hosted in Vancouver and includes storage, traffic, email accounts, SSL certificates, free migration, uptime guarantees, monitoring and support. Its technical specification section names SSD/NVMe drives, 10 Gigabit per second bandwidth, shared IPv4 and IPv6, CloudLinux, AMD EPYC processors and a server located in Vancouver. The VPS page also lists Vancouver as the location for managed virtual private server plans, with IPv4 and IPv6, NVMe storage, remote backup storage and a 99.99 percent uptime SLA. The managed dedicated server page gives the same Vancouver location and a 2 Gbps bandwidth figure for its listed plans.
That geography is commercially meaningful. A small Canadian business that wants Canadian-dollar billing, local support norms, Canadian domain services and data stored in Canada may rationally prefer a Vancouver-hosted provider over a hyperscale platform whose data placement and legal control are harder to reason about. StormWeb's cloud-storage page makes that appeal explicit by describing Nextcloud-based storage on Canadian servers in Vancouver and framing Canadian privacy law as part of the value proposition.
But locality is not the same as independence. A customer that sees "hosted in Vancouver" still needs to know which Vancouver data-centre site, which utility feed, which building power path, which carrier entrances, which upstreams, which storage platform, which backup target and which staff rota are involved. If all products sit behind the same Vancouver core, then a Vancouver building event, metro-fibre cut, upstream maintenance error, storage controller fault or support overload can affect services that look separate on the sales menu.
Vancouver also creates a specific network context. VANIX publishes facility connection points including Cologix VAN2 at 1050 West Pender Street, Cologix VAN3, Cologix VAN4 and an eStruxture facility at 555 West Hastings Street. Cologix's VAN2 page describes 1050 West Pender as an enterprise-grade annex connected to the city's primary carrier hotel and says the location provides direct access to VANIX. Those pages support the idea that Vancouver has a real interconnection market, not merely a marketing label. They do not tell us where StormWeb's production servers reside or whether StormWeb has equipment in one or more of those buildings.
The safest reading is that StormWeb's public geography is precise enough for customer positioning and limited public evidence for resilience proof. "Vancouver" tells a buyer about jurisdiction and latency. It does not settle whether the service can survive the loss of a rack, switch, data-centre hall, power distribution unit, cooling zone, storage node, transit provider or account-management system. Buyers should ask for a site map under confidentiality, but the public article should not invent the answer.
AS14807 makes StormWeb a network operator, not only a retail host
The strongest third-party operating evidence is the network record. ARIN's AS14807 record names STORMWEB, identifies the organization as StormWeb Canada Hosting Inc., gives a February 2024 registration date and a May 2026 update, and lists both as14807.net and stormweb.ca in the comments. That does not prove how many servers StormWeb runs, but it establishes control of an autonomous system under the company's name.
PeeringDB's AS14807 page adds useful operational texture. It lists the organization as StormWeb, the also-known-as name as StormWeb Canada Hosting Inc., the IRR as-set as AS-STORMWEB, the geographic scope as North America, traffic levels as not disclosed, traffic ratio as mostly outbound, and a public peering exchange point at VANIX. The VANIX entry is shown as operational with 10G capacity and addresses 206.41.104.51 and 2001:504:39::51.
VANIX's own entity list corroborates the same member identity, ASN and IPv4/IPv6 exchange addresses. Hurricane Electric's VANIX exchange page also lists AS14807, StormWeb Canada Hosting Inc., and the same exchange addresses among a large set of Vancouver entities. IPinfo's AS14807 page lists three IPv4 blocks associated with StormWeb Canada Hosting Inc., while ipctl's AS14807 view reports three IPv4 announced prefixes, one IPv6 prefix, RPKI-valid status and upstream-provider data that includes GTT, Hurricane Electric and Astute Internet.
Taken together, these records make the network presence credible. StormWeb is not simply reselling a white-labelled control panel with no visible routing footprint. It has a public ASN, route objects, exchange membership and upstream visibility. That improves the customer story because direct routing control can make troubleshooting, peering and traffic engineering more practical than a pure reseller model.
But AS ownership is not a resilience guarantee. A 10G exchange port does not prove active traffic volume, spare capacity during an incident, redundant switches, dual power to every router, diverse fibre into the facility, or the ability to keep hosted servers reachable if the main Vancouver site loses power or cooling. PeeringDB explicitly marks StormWeb's traffic levels as not disclosed, and public BGP views do not reveal customer impact, port utilisation, maintenance history or failover tests.
The presence of upstream providers also needs careful reading. Multiple upstreams in BGP data are good evidence of routing options. They do not automatically prove physical path diversity. Two upstream sessions can traverse the same meet-me room, the same local duct, the same optical shelf, the same building power domain or the same support process. Customers buying high-availability hosting should ask whether StormWeb's upstreams terminate in separate devices, separate cabinets, separate facilities, separate carrier entrances and separately powered paths.
Without that evidence, AS14807 supports a Medium network grade, not a Strong resilience grade.
The service catalogue shows real products and hidden contention
StormWeb's retail catalogue is broad enough to matter. The web-hosting page offers Starter, Pro and Enterprise web-and-email plans, with the visible tiers moving from one site and 100GB of SSD/NVMe storage to unlimited sites, unlimited SSD/NVMe storage and unlimited email accounts. It also lists free SSL certificates, migration help, uptime guarantees and 24/7 monitoring and support. The technical section points to CloudLinux, Apache, MariaDB, multiple PHP versions, SSH/SFTP and other ordinary small-business hosting components.
The VPS page lists managed virtual private server plans from 25GB to 500GB of storage, 100 Mbps to 1 Gbps of bandwidth, one to six vCores, 4GB to 24GB of RAM and remote backup storage. The managed dedicated server page lists larger plans with 1TB to 6TB of storage, 2 Gbps bandwidth, 8 to 24 dedicated vCores, 32GB to 96GB of RAM and remote backup storage. The cloud-storage page presents 1TB, 2TB and 5TB Nextcloud options, hosted in Vancouver with monitoring and support.
These are not exotic services. They are exactly the services that small businesses buy when they want to avoid running infrastructure themselves. That makes the dependency problem sharper. Small-business hosting often looks simple because the customer sees one invoice and one login. The provider still has to ration disk, CPU, RAM, I/O, snapshots, mail queues, restore labour, IP addresses, support time and upstream transit. When the product page uses words such as "unlimited" or "unmetered," the engineering reality still has limits.
StormWeb's own acceptable use policy confirms that shared capacity is actively bounded. It says the service is designed for small, independently owned businesses, not large enterprises or internationally based businesses with sustained demand that burdens the system. It also describes shared web hosting as many customers' websites and email or storage services hosted from the same server, with abuse controls intended to prevent one customer from harming others. The same policy places CPU-duration limits on shared hosting and restricts uses such as file sharing, gaming servers and unattended processes.
That policy language is sensible. Shared hosting cannot work without guardrails. It also means customers should not read the sales page as a promise of unconstrained computing capacity. StormWeb is selling managed, bounded hosting capacity for a particular customer class. If a site grows unusually fast, gets scraped, sends mail badly, runs heavy scripts or becomes a storage substitute, the provider's controls can become part of the customer's availability path.
The economics are visible in the price ladder. Low monthly prices, bundled migration, included certificates, support and backups all depend on multi-tenant efficiency. Multi-tenant efficiency depends on contention management. Contention management depends on accurate monitoring, fair throttles, upgrade paths and support escalation. The key customer question is not whether StormWeb's catalogue is real. It is how the company separates normal small-business use from load that forces a migration, suspension, paid upgrade or manual repair window.
Uptime guarantees define credits, not engineering proof
StormWeb's product pages advertise uptime guarantees: 99.9 percent on lower shared hosting tiers, 99.95 percent on the Pro shared plan, 99.99 percent on the Enterprise shared tier and 99.99 percent on VPS and managed dedicated server plans. The contract page is more revealing than the sales page. StormWeb's terms of service say the exact uptime guarantee is listed in the plan description, define network unavailability as 100 percent packet loss from StormWeb to its backbone providers, and measure downtime after notification through the online ticketing system, with a phone call fallback if the ticketing system is unreachable.
That definition is narrow. It may be appropriate for a hosting credit policy, but it is not the same as application availability. A customer's site can be commercially unavailable because a database is overloaded, a mailbox is locked, a control panel fails, a backup snapshot hurts performance, a DNS configuration is wrong, a certificate renewal breaks, a storage pool slows, a script consumes CPU, or a customer's own code fails. Some of those incidents may fall outside a network packet-loss definition.
The exclusions are equally important. The terms exclude scheduled maintenance, customer behaviour or equipment, circumstances beyond StormWeb's reasonable control, interruption or delay in telecommunications or third-party services, DNS propagation, domain registration or transfer, third-party software or hardware, and inability to obtain raw materials, supplies, power or equipment. Those exclusions are normal in hosting contracts. They also identify the physical supply chain behind the promise: power, transport, third-party software, hardware, materials and maintenance all remain dependencies.
The limitation-of-liability section is another economic signal. The terms say services are provided without a warranty that they will be uninterrupted, error-free or completely secure, and cap aggregate liability at an amount tied to three months of service. That is not unusual for small-business hosting. It simply means the customer's loss model cannot be outsourced to the SLA. If a customer's revenue, reputation, regulated data or operational process depends on the hosted system, credits and capped damages will not make the customer whole.
The recovery provisions should be read alongside the uptime promise. The terms say customers agree to maintain a current copy of all content hosted by StormWeb, notwithstanding any agreement by StormWeb to provide backup services. They also describe one free restore request during a service term, with a fee after that. This does not mean StormWeb lacks backups. It means the contract places ultimate content-copy responsibility on the customer. A business that treats provider backups as its only backup has misunderstood the allocation of risk.
The practical reading is that StormWeb offers a conventional hosting SLA, not proof of end-to-end resilience. A buyer should ask how uptime is monitored, which services are covered, how storage and mail faults are treated, how maintenance is announced, how credits are requested, how restore points are created and tested, and how quickly the company can rebuild a VPS or mailbox onto different hardware. The answer, not the percentage, determines usable availability.
Maintenance and incident notes expose the real failure paths
StormWeb's announcement page is valuable because it shows how the service can fail and how the company communicates. The announcements index includes product updates, price changes, maintenance notices and incident posts. A November 2025 Vancouver core-router maintenance notice said StormWeb would upgrade core routers at its Vancouver point of presence, expected to maintain redundant network connections to servers during the window, but noted the possibility of brief internet-connectivity issues for clients. That is a precise statement of the network risk: redundancy is intended, but a core-router change can still be customer-visible.
The October 2025 shared-hosting outage notice is even more instructive. It says web and email services for some shared-hosting clients were unavailable between 3:30 and 9:30 am EDT because an automated snapshotting process during a scheduled backup caused unexpected performance degradation. The company says it took steps to prevent recurrence. This is not a reason to label StormWeb unreliable. It is evidence that backup and snapshot work is part of the live risk surface.
The April 2024 IMAP and POP3 disruption notice describes a detected fault in one email server, restoration after roughly 25 minutes, and an automatic software update that was incompatible with server configuration. That incident sits in a different category: not transit, not power, but software-change compatibility. For small-business customers, email outages can be more harmful than a brief website issue because invoicing, support and account recovery often depend on mail.
Several older posts show planned hardware work. The October 2024 da2 server maintenance notice said web, email and control-panel services would be unavailable during a four-hour window while hardware was upgraded, and later marked the upgrade complete. The adjacent da1 maintenance notice follows the same pattern. These notices are useful because they locate downtime at server hardware and control-panel layers rather than only at the network edge.
The lesson is not that maintenance is bad. Maintenance is how service remains safe. The lesson is that customers should model maintenance as a capacity constraint. If a provider must take a shared server down for hardware work, the customer's resilience depends on whether the workload can move elsewhere, whether mail queues are preserved, whether the maintenance window is tolerable, and whether the customer has an independent copy of the site. If a router upgrade can create brief internet issues despite redundant connections, then high-availability customers need either a second path or tolerance for short events.
Backups are a dependency, not a cure
Backup language often calms buyers too quickly. StormWeb's product pages list remote backup storage for VPS and managed dedicated server plans, and its cloud-storage page sells Nextcloud capacity as a user-facing product. The incident record shows why backup design needs scrutiny. The October 2025 shared-hosting outage was tied not to data loss but to a scheduled backup snapshot that created unexpected performance degradation. That is a classic infrastructure problem: the protective system can become the disruptive system when snapshot load, storage performance, database I/O or scheduling does not match the live workload.
StormWeb's contractual backup language is clear that the customer remains responsible for a current copy. That is a healthy warning. A backup is only useful if it exists, is recent enough, can be accessed when the provider is impaired, and can be restored somewhere else quickly. A backup stored on the same provider's platform may help after accidental deletion; it may not help if account access, billing, storage, routing or the provider's support queue is the thing that failed.
Shared hosting raises a special issue. Many customers on one physical or virtual server can have backups scheduled in the same window. The provider has to balance backup frequency, storage cost, I/O impact, restore granularity and operational labour. If the backup creates performance drag, customers experience it as downtime. If backups are too infrequent, restores lose too much data. If restores require support staff, a widespread issue can create a queue. If a backup is provider-internal only, it may not help a customer migrate under stress.
VPS and dedicated plans shift some of the problem but do not remove it. Remote backup storage sounds stronger than local-only storage, but the public plan table does not identify the backup system, retention schedule, physical location, encryption model, restore speed, network path, failure domain or whether backups are customer-downloadable. A customer running accounting software, a booking system, a legal document store or a clinic website needs more than a storage number. It needs a restore objective.
Cloud storage has the same trap in reverse. StormWeb's cloud-storage page markets Nextcloud, Canadian hosting, encryption in transit, folder-level encryption at rest and support. That can be useful for teams that need a Canadian file-sharing service. But cloud storage is not the same thing as disaster recovery. If users accidentally delete or overwrite files, if encryption keys are mishandled, if the account is suspended, if the Vancouver platform is degraded, or if the provider changes the service, the customer still needs retention, export and restore evidence.
The test for StormWeb customers is simple and demanding. They should ask when backups run, where they are stored, how long they are retained, whether they are isolated from the primary system, whether they are encrypted, whether customers can download them without support intervention, how restores are prioritised, and when the last full restore was tested. Without those answers, backup is a feature, not a recovery guarantee.
Data locality is a value proposition with boundaries
StormWeb's Canadian positioning is credible and commercially useful. The company says it is 100 percent Canadian owned, lists a Canadian office, prices in Canadian dollars, and locates servers in Vancouver. Its privacy policy says it does not sell personally identifiable information and describes use of information for transactions, support and service announcements. Its cloud-storage page says files are stored on secure servers hosted in Vancouver. For many customers, those facts reduce friction.
The broader legal context still requires care. The Office of the Privacy Commissioner of Canada's cloud-computing guidance for small and medium-sized enterprises frames cloud computing as a privacy and accountability problem, not simply a storage-location problem. The OPC's outsourcing guidance also makes the key point for private-sector customers: outsourcing data processing is allowed under PIPEDA, but organizations remain responsible for privacy considerations and should use contractual or other means to protect personal information.
British Columbia public-sector buyers face additional analysis. Provincial guidance on disclosures outside Canada tells public bodies to assess risks when cloud or infrastructure providers may be subject to laws that compel disclosure. The relevant point for StormWeb is not that it fails this test. It is that "Canadian-owned" and "hosted in Vancouver" do not complete the test by themselves. A buyer still needs contract terms, subcontractor disclosure, support-access geography, backup geography, log handling, legal-process handling and data-export mechanics.
StormWeb's terms say the agreement is governed by British Columbia law and Canadian law as applicable. That helps define the contract forum. It does not by itself prove that every support tool, payment processor, registrar, software vendor, monitoring system, backup target or upstream service is Canadian. The privacy policy also mentions third-party services for payment processing and tracking, which is normal. Buyers with strict locality needs should ask which third parties process account, billing, support, monitoring and backup data.
There is a practical difference between data residency and data portability. Data residency asks where the data sits. Data portability asks how fast the customer can leave. A Canadian small business may choose StormWeb to keep its website, mail and files in Vancouver. If it later needs to move because of price, performance, acquisition, support, compliance or an incident, it must be able to export DNS, mailboxes, databases, site files, Nextcloud files, VPS images and logs without a week-long manual dependency.
The locality grade is therefore Medium. StormWeb's Canadian ownership, office, Vancouver hosting claim, domain-registration position and privacy-facing language are useful. The missing evidence is the full subcontractor and recovery map. For sensitive workloads, customers should treat Canadian locality as a starting advantage, not the final control.
VANIX improves reach, but does not prove route diversity
StormWeb's VANIX participation is one of the strongest parts of its infrastructure story. A local exchange can lower latency, keep regional traffic local, reduce transit cost and improve route choice. StormWeb's own about page mentions VANIX participation and says peering with other prominent Canadian networks helps reduce latency by keeping local traffic local. The public exchange records support that claim at the membership level.
The exchange ecosystem also gives useful context. VANIX's entity list includes major content, telecom, cloud, enterprise and network operators. Hurricane Electric's exchange view shows StormWeb among a dense set of Vancouver peers. VANIX's history page reports traffic milestones and backbone upgrades over recent years, including 400G links and entity-traffic growth. These records support the conclusion that StormWeb is attached to a meaningful local interconnection environment.
The risk is over-reading the evidence. A single 10G exchange connection can improve reach and economics, but it does not guarantee customer service continuity. If StormWeb's routers, servers and backup targets all sit behind one Vancouver site, one internal switch path or one maintenance process, then VANIX membership only solves part of the problem.
If a customer needs guaranteed low-latency access to a particular peer, the customer also needs to know whether the route stays local during maintenance, whether the provider has a second exchange port, whether route-server sessions are redundant, whether BFD is configured and whether traffic can move to transit without overload.
The upstream-provider story needs the same discipline. ipctl reports GTT, Hurricane Electric and Astute Internet as upstream providers for AS14807. Multiple upstream names are better than one. Yet public BGP does not reveal whether those upstreams are physically diverse, whether they terminate on different routers, whether they share an optical path, whether their contracts include restoration intervals, or whether StormWeb can absorb the loss of one during peak shared-hosting traffic. Customers should ask for a route-diversity drawing and failure-test evidence rather than relying on the list of AS names.
StormWeb's 2025 core-router maintenance notice is the most practical proof that the network has moving parts. It says redundant network connections were expected to remain, but brief connectivity issues were possible. That wording is neither alarming nor empty. It is what real maintenance looks like when a small provider has redundancy but still has to touch the core. For a customer, the right response is not to demand zero maintenance. It is to decide whether the application can tolerate a brief connectivity issue and, if not, to design a second provider path.
The network grade should therefore remain split. StormWeb deserves credit for a public ASN, exchange participation, visible routes and a maintained network identity. It does not deserve an invented proof of route diversity, measured packet-loss history, port utilisation, exchange-fabric failover or multi-site recovery. The public file supports active network operations and leaves the diversity test open.
Who is affected when the system fails
StormWeb's customer base is not publicly enumerated, and the article should not invent named customers. The product pages make the affected groups clear enough. Shared web-and-email customers include small organizations using the platform for websites, mailboxes, WordPress, databases and contact forms. VPS customers may run more customised applications, control panels, databases and mail stacks. Managed dedicated server customers may be consolidating higher-resource applications onto StormWeb-managed capacity. Cloud-storage customers may use Nextcloud for files shared among devices and team members.
The failure mode decides the impact. A shared server hardware maintenance window can make web, email and control-panel services unavailable for the affected customers. A backup snapshot performance issue can block web and email access without destroying data. An incompatible software update can interrupt mail protocols. A core-router maintenance issue can affect internet reachability even if servers remain powered. A billing suspension can remove service for a nontechnical reason. An abuse-control trigger can throttle or suspend a site that grew faster than expected.
Each affected group has a different tolerance. A brochure site can survive a planned 1:00 am maintenance window. A restaurant reservation system, clinic site, ecommerce store, legal mailbox or emergency community page may not. A freelancer using Nextcloud as a convenience store can wait for a support response; a distributed office using it as the primary file system needs offline copies and export procedures. A VPS user may have enough technical ability to replicate elsewhere; a shared-hosting user may depend entirely on provider support.
The contract language makes this a customer design issue. Customers are responsible for maintaining a current copy of hosted content. Scheduled maintenance is excluded. Provider liability is limited. Abuse and resource policies can be enforced. The service can change as software, hardware and service providers change. Those clauses are commercially normal, but they transfer much of the continuity burden back to the customer.
This is where support becomes infrastructure. StormWeb says support staff are available 24 hours a day for support requests, and product pages repeatedly list monitoring and support. The contact page states phone hours during office time and points existing-service issues toward announcements, network status, knowledgebase and tickets. The network status page lists web, mail, database, FTP, SSH/SFTP and DNS services across web/email hosting, VPS, dedicated servers and cloud storage, and provides a current-status surface.
That is useful, but not enough for high-consequence use. Customers should ask how urgent tickets are triaged, whether phone escalation exists for outages, how after-hours staffing works, whether support has authority to move workloads, how restore requests are queued, and how incident updates are distributed if the client area is unreachable. In a small-provider setting, support labour is as real a capacity constraint as CPU or disk.
What a buyer should verify before treating StormWeb as resilient
The first verification item is facility location and failure domain. StormWeb publicly says Vancouver, but a resilience buyer needs the data-centre operator, site, room or cage boundary, power feeds, UPS design, generator runtime, cooling redundancy, fire suppression, physical security, and whether production, backup and network gear share the same facility. If the provider will not disclose details publicly, a confidential evidence package is reasonable.
The second item is network diversity. AS14807 and VANIX are good starting evidence. The buyer should ask for upstream list, port speeds, router redundancy, facility diversity, carrier entrances, route-server use, private-peering policy, DDoS handling, and how traffic behaves when one upstream, one router or one exchange session fails. The key phrase is not "Do you have multiple providers?" but "Show the separate failure domains."
The third item is capacity and inventory. The public plan pages list storage, traffic, bandwidth, CPU and RAM, but they do not reveal contention. A buyer should ask how many customers share a host, how CPU and I/O are controlled, what happens when a host fills, whether spare hardware is on hand, how quickly a VPS can be rebuilt, how licences are handled during failover, and whether "unmetered" or "unlimited" has operational thresholds beyond the policy text.
The fourth item is backup and restore. A buyer should ask for backup frequency, retention, target location, encryption, integrity checks, restore test history, customer-download rights, restore priority and the cost of extra restores. If the customer needs provider-independent recovery, it should maintain its own backups outside StormWeb. If the customer needs near-real-time continuity, ordinary shared-hosting backups are not enough.
The fifth item is maintenance. StormWeb's announcements show planned hardware and router work, which is normal. Customers should ask how far ahead maintenance is announced, how emergency work is handled, whether there are blackout dates, how maintenance affects SLA credits, whether customer workloads can be moved, and whether the provider has a tested rollback process. Planned downtime is still downtime for the customer's users.
The sixth item is portability. For web hosting, the customer needs site files, databases, DNS records, mailboxes, spam settings and certificates. For VPS, it needs images or configuration management, not only file backups. For cloud storage, it needs bulk export, version history, deleted-file retention and account-owner access. For domains, it needs transfer codes and registrar account control. Canadian locality is less useful if exit takes too long.
The seventh item is support escalation. The buyer should know the difference between ticket support, office-hours phone help, after-hours incident response, billing support and emergency restoration. A provider can have skilled staff and still bottleneck during a multi-customer event. The contract should state who can authorize work, how identity is verified and how the customer receives updates when email itself is affected.
None of these questions assumes bad faith. They are the ordinary due-diligence items needed when a hosted service becomes operational infrastructure. StormWeb's public evidence is adequate for a normal small-business hosting shortlist. It is incomplete for a buyer that wants to treat the service as a resilient platform without additional proof.
The evidence grade must stay split
StormWeb Canada Hosting Inc. has enough public evidence to avoid the "thin footprint" problem that often surrounds small hosting companies. Its website is active, its company name and contact details are visible, it claims a 1998 founding and Canadian ownership, it lists Vancouver-hosted products, it operates AS14807, it appears in ARIN, PeeringDB, VANIX and BGP data, and it publishes announcements that include maintenance and incident information. That supports a Medium evidence grade for identity, service catalogue and network operations.
The same public file leaves major resilience questions unresolved. StormWeb does not publish a data-centre address for production servers, the facility operator for customer workloads, power architecture, generator runtime, cooling design, rack or server inventory, storage topology, backup isolation, customer restore statistics, exchange-port utilisation, upstream physical diversity, support staffing depth, or multi-site recovery plan. Its own contract and incident notes point to the real dependencies: scheduled maintenance, third-party services, hardware, software, power, backup processes, support tickets and customer-held copies.
The editorial conclusion is therefore not that StormWeb is unsafe. It is that StormWeb sells ordinary hosted capacity whose reliability cannot be inferred from Canadian branding, uptime percentages or an exchange port. The capacity becomes dependable only when the physical and operational layers are evidenced: racks, power, cooling, transit, server stock, backup restore, maintenance controls and data portability.
For many small businesses, StormWeb may be a reasonable Canadian hosting provider, especially where Vancouver locality, Canadian-dollar billing, domain registration, managed support and shared-hosting simplicity matter more than formal high-availability engineering. For customers whose websites, mailboxes, files or applications are business-critical, the right posture is stricter. Use the public evidence as a starting map, ask for private proof where needed, maintain independent backups, test restores, keep DNS and domain control portable, and design a second path if downtime is expensive.
Final evidence grade: Medium for operating identity and network presence; Weak for public proof of facility resilience and customer recovery. The buyer should not confuse StormWeb's visible network with a verified resilient platform until the hidden layers are documented and tested.