Summary
- WiseTech Global is not a South African VPS or bare-metal seller. It is an Australian-listed logistics-software group whose CargoWise application is delivered from a mixture of WiseTech-managed infrastructure, Equinix colocation and large cloud suppliers. Its South African subsidiary and Johannesburg support numbers establish a local operating presence, but its current public security material does not identify a South African customer-data centre.
- The company's January 2026 SOC 3 report names customer-domain hosting in Sydney, Chicago, Hamburg, China and Saudi Arabia. It also identifies Equinix, Microsoft Azure, Amazon Web Services and Alibaba Cloud as material service providers. That is unusually concrete infrastructure disclosure, yet it does not publish server counts, available headroom, recovery-time objectives, recovery-point objectives or customer-by-customer failover assignments.
- AS397950 is a real ARIN registration tied to WiseTech Global's US organisation and a registered /24 address block. Current route observation shows no IPv4 or IPv6 announcement, no visible neighbour and no public route-origin authorisation. Historical observation last saw 207.188.5.0/24 originated by AS397950 in July 2021. The number supports identity and past network operation, not a claim that it currently carries CargoWise traffic or serves South Africa.
- WiseTech says production customer data is held at a minimum of two sites for disaster recovery, backups are copied to Azure or Equinix storage, and customer document files use dedicated AWS S3 buckets. Those controls reduce some failure risks, but they create a chain of facility, network, storage, software and supplier dependencies whose contractual boundaries matter as much as the number of sites.
- A June 2026 CargoWise incident reportedly disrupted logins and electronic messaging across hosted and self-hosted customers for about two hours. The event is a reminder that geographic redundancy cannot prevent a common software or reference-data fault. Buyers need tested degraded-mode procedures, independent communications and a practical data-exit plan, not only a count of data centres.
The subscription ends in a rack
CargoWise is sold at the level of workflow. A freight forwarder logs in, creates a shipment, exchanges messages with carriers, prepares customs work, books transport, records warehouse movements and issues accounting entries. The customer does not usually need to know which disk holds a document or which switch forwards a session. That concealment is the point of a hosted service: WiseTech absorbs much of the hardware ownership, patching, backup and application-delivery work that would otherwise sit with each logistics company.
The abstraction can become misleading when it is treated as weightless. A database still consumes processors, memory and storage. A customer session still crosses local access networks, long-haul carriers, firewalls and load-balancing equipment. Every replica occupies capacity somewhere. Every backup has a retention policy and a restore path. Every failed component has to be identified, removed and replaced, often inside a building whose access rules are controlled by a different company. Even a software defect that leaves all the hardware healthy must be diagnosed and corrected by people with the right privileges.
WiseTech's own 2025 annual report describes the performance and availability of its platform, data centres and global communications systems, including servers, internet connections, hosting services and cloud environments, as critical to the business. It expressly recognises disruption, service outages and data corruption as risks. That language is more useful than a generic assurance that the service is “in the cloud”, because it identifies the actual categories that can stop the application.
The economic scale makes those categories consequential. The annual report says FY25 CargoWise revenue reached US$682.2 million, total group revenue reached US$778.7 million and recurring revenue represented 98% of group revenue. It reports customer attrition below 1% for more than a decade. CargoWise's current product site says more than 17,000 organisations use the platform across 193 countries. A service with that commercial reach is not merely an application running in one office. It is operating infrastructure for companies that coordinate cargo, declarations, invoices and inventory across time zones.
High recurring revenue also changes the provider's incentives. WiseTech can spread data-centre, network, security and support costs across a large installed base, gaining economies unavailable to a single forwarder. It can standardise upgrades, buy colocation at scale and retain specialists. At the same time, customers consolidate more operational dependence onto one service. The provider's efficient shared platform becomes the customer's concentration risk.
That is the central bargain. Hosted capacity removes the customer's need to own every server, but it does not remove scarcity, maintenance or failure. It transfers decisions about spare hardware, power, transit, release timing and restoration priority to WiseTech and its suppliers. A serious infrastructure assessment therefore asks where those responsibilities sit, which facts are public, which are contractual and which remain unproven.
First fix the identity: one group, several geographic clues
The name WiseTech Global can produce a misleading research trail. It belongs to an Australian-listed software group, while public network records for AS397950 point to a US organisation in Schaumburg, Illinois, and the commissioned regional context is South Africa. These are not three unrelated businesses, but they are also not interchangeable evidence.
WiseTech Global Limited is the listed parent. Its annual report identifies Wisetechglobal (Pty) Ltd, Compu-Clearing (Pty) Ltd and Core Freight Systems (Pty) Ltd as South African subsidiaries at 30 June 2025. The company's current contact page lists a Johannesburg office at 173 Oxford Road in Rosebank and gives a South African support number. CargoWise's support page separately advertises round-the-clock incident reporting and an Africa telephone number. Together, those records establish a corporate and support presence in South Africa.
They do not establish a South African cloud region. WiseTech's privacy help centre says its data centres are in Germany, the United States and Australia. The current SOC 3 adds China and Saudi Arabia cloud instances for specific customer-domain hosting. Neither document names Johannesburg, Cape Town or another South African city as a CargoWise hosting location.
This distinction matters because office location, contracting entity, support location, data processing location and internet-route origin answer different questions. A Johannesburg employee can support a customer whose primary system is in Germany. A South African subsidiary can invoice for a service delivered from Chicago. A US autonomous system can belong to the same corporate group without carrying traffic for the South African operation. None of these arrangements is inherently improper; they simply require accurate labels.
The same caution applies to the word “global”. CargoWise is a global application in functional reach and customer use. It does not follow that every geography has an interchangeable local copy or that every customer can choose any site. A globally available service may still place one customer domain in a particular hosting region, replicate it to a defined recovery destination and route support through a separate team.
WiseTech's current Data Processing Addendum makes the contracting boundary explicit: “WTG” means the WiseTech entity named in the customer's service agreement. That is the entity against which data-processing duties operate. For a South African buyer, the company name on the order form is therefore not clerical detail. It determines which group entity is the processor and which law and liability terms attach to the service.
A defensible reading is consequently narrow. WiseTech has a verified South African company and customer-support footprint. It has verified hosted infrastructure in other named regions. It has a US network registration linked to its US operation. Public evidence does not join those facts into a WiseTech-owned South African network or a local South African CargoWise hosting region.
AS397950 proves less, and more, than a logo on an ASN page
AS397950 is the cleanest place to see why registration, routing and service delivery must be separated. The ARIN registration for AS397950 names the autonomous system TRIN-01, marks the registration active, records an allocation date of 18 September 2019 and identifies organisation handle WGU-4 as the registrant. The corresponding ARIN organisation record names WiseTech Global and gives the 1051 East Woodfield Road address in Schaumburg, Illinois. WiseTech's current subprocessor disclosure lists WiseTech Global (US) Inc at the same address, reinforcing the corporate connection.
ARIN also maintains an active registration for 207.188.5.0/24, covering 256 IPv4 addresses and tied to WGU-4. That establishes a registered address resource. It does not mean all 256 addresses are assigned to servers, that any are reachable today or that the block hosts CargoWise.
Current routing observation is negative. RIPEstat's announced-prefixes result returns no IPv4 or IPv6 prefixes for AS397950. Its routing-status result shows no announced address space and no route-collector peers seeing the autonomous system in either protocol. Its neighbour result returns no current adjacent networks. IPinfo's AS397950 page independently labels the network inactive and reports no hosted addresses, while Cloudflare's routing view preserves the registered identity but does not turn registration into proof of a production route.
The history is more informative. RIPEstat's routing-history result shows 207.188.5.0/24 originated by AS397950 during several periods beginning in December 2019 and ending in July 2021. The routing-status record identifies 27 July 2021 as the last observation. This is evidence of past route operation, not merely a reserved number.
There is no current route-origin authorisation to assess for a live announcement. A RIPEstat validation query for the historical prefix returns no validating authorisation and an unknown status. That does not make the dormant registration illegitimate. It means a future reactivation would need fresh examination of the observed origin and authorisation state.
The evidence therefore has two simultaneous meanings. AS397950 strengthens corporate identity: ARIN ties a specific network resource and address block to WiseTech Global's US record. It also weakens any claim that the number describes present service delivery: public route collectors have not seen it originate a route for roughly five years. An ASN directory that displays “active” may be describing registration status while an internet observer describing it as inactive is describing route visibility. Both can be accurate within their domains.
Most importantly, AS397950 is not South African evidence. ARIN places the registrant in the United States. No current route path links the number to Johannesburg. No WiseTech document reviewed here says CargoWise customer traffic uses it. The right conclusion is that WiseTech has retained a registered US network identity and /24, with historical routing but no present public announcement. Anything stronger would confuse the address-resource layer with the much larger hosted-service estate disclosed elsewhere.
The physical estate is a hybrid, not a single cloud
WiseTech's January 2026 SOC 3 report for CargoWise provides the clearest public description of that estate. It covers controls during the period from 1 October 2024 to 30 September 2025 and identifies the CargoWise application hosted on CargoWise Cloud as the system under review.
The report lists five customer-domain hosting locations or environments:
- A Sydney data centre operated as Equinix colocation.
- A Chicago data centre hosted and managed by WiseTech.
- A Hamburg data centre operated as Equinix colocation.
- A China cloud instance hosted on Alibaba Cloud.
- A Saudi Arabia cloud instance hosted on Alibaba Cloud.
This is a materially different architecture from a service that simply rents anonymous virtual machines from one hyperscale supplier. WiseTech directly manages the Chicago site, places equipment or services in Equinix facilities in Sydney and Hamburg, and uses Alibaba Cloud for the two specified country environments. The report also names Microsoft Azure for backup and storage and Amazon Web Services for client-data storage.
Each relationship has a different control boundary. In Chicago, WiseTech says it manages the data centre, so its responsibility extends deeply into on-site operations. At Equinix, WiseTech depends on the facility operator for colocation services and backup storage while retaining responsibility for its own equipment and configuration. In Alibaba Cloud, it consumes cloud instances and relies on the supplier's contracted availability. In Azure and AWS, it uses storage services supporting backup and customer documents.
WiseTech's subprocessor list adds another network dependency: Aryaka Networks supplies acceleration over the public internet. It also identifies the internal data-centre companies as WiseTech Global Limited in Australia, WiseTech Global (US) Inc and CargoWise GmbH in Germany. This supports the three-region core described in the annual report and privacy material.
The architecture is diversified, but diversification should not be read as interchangeability. The SOC 3 does not say every customer domain runs simultaneously in all five environments. China and Saudi Arabia are described as specific cloud instances. WiseTech's annual report speaks of separate data centres in three regions, consistent with Australia, the US and Germany as the principal estate. A customer cannot infer that a Sydney workload can instantly run in Saudi Arabia or that data held for a Johannesburg company has a live copy in every location.
The report's dependence on named suppliers also matters. Equinix advertises redundant power, cooling and network paths, but a tenant benefits only from the feeds and cross-connects it actually buys and configures. Microsoft explains that Azure Backup resilience depends on the chosen vault redundancy. AWS says standard S3 classes store entities across at least three availability zones, while one-zone classes have a different failure boundary in its S3 durability guidance. Supplier capability is the ceiling; WiseTech's purchased design and customer assignment determine the realised protection.
The public disclosures establish a credible hybrid hosting estate. They do not reveal rack counts, server generations, storage arrays, carrier names at each core site, power reservations, available remote-hands contracts or spare-part holdings. Those omissions are normal for a security-conscious operator, but they leave installed and recoverable capacity as contractual rather than publicly measurable facts.
Installed capacity is not the same as usable capacity
The word capacity sounds numerical, yet the number that matters changes with the failure being tested. A data-centre hall may have room for another rack but no reserved power for it. A rack may have power but no server inventory. A cluster may have spare processors but no storage performance at peak load. A recovery site may hold a replica but lack enough headroom to absorb all affected customers at once. A support team may have tools but not immediate building access.
WiseTech says it monitors customer environments and internal infrastructure against performance, capacity and uptime thresholds. That is evidence of an operating discipline, not a disclosure of the thresholds. Customers still need to distinguish at least four layers.
Registered capacity includes assets such as AS397950 and 207.188.5.0/24. These can support network operation, but they are not presently visible as routes. Installed capacity includes running servers, storage, network equipment and leased cloud instances. WiseTech's SOC 3 proves that such systems exist at named locations, but does not quantify them. Usable capacity is what can serve production after maintenance margins, reserved growth and component failures are considered. Recoverable capacity is what remains when a site or shared service has failed and workloads must move or restore elsewhere.
The difference is commercially significant. Suppose the Chicago environment loses a rack. If affected customer instances are distributed across other racks with redundant storage, impact may be small. If a storage or network component serves many racks, the blast radius may be larger. Suppose the entire site is unavailable. A valid off-site backup preserves data, but restoration still requires compute, storage, network and staff at the destination. The recovery copy is not equivalent to hot capacity unless the destination is already provisioned and tested for the relevant load.
WiseTech's high gross margin and recurring-revenue base suggest it has the financial ability to invest in resilience. The FY25 annual report records an 86% gross margin, US$167.4 million in cash at year end and substantial product investment. Those numbers say the group is not a thinly capitalised local hosting reseller. They still do not tell a customer whether a particular recovery site has 20%, 50% or 100% spare headroom for simultaneous failover.
Cost efficiency adds a second tension. WiseTech reported a US$40 million annual run-rate saving programme in FY25. Operational efficiency can remove duplication and improve standardisation. It can also make customers ask whether buffers in support labour, hardware stock or infrastructure have been reduced. The annual report says data-centre monitoring and CargoWise reliability were management objectives, which is reassuring, but no public metric connects the savings programme to spare capacity.
The customer response should not be to demand a public server inventory. It should be to seek service-specific answers: the production region; the recovery region; the designed simultaneous-failure scenario; the committed restoration objective; the measured result of the latest relevant exercise; and any capacity shortfall that would force staged recovery. Those facts turn “multiple data centres” into a usable resilience proposition.
Replication protects data; it does not guarantee immediate service
The SOC 3 describes several layers of data protection. It says virtual images or systems receive scheduled full and incremental backups at WiseTech-managed sites, Equinix colocation and Alibaba Cloud, and that backups are copied to Azure storage or Equinix backup facilities. It says AWS S3 stores CargoWise electronic documents, with a dedicated bucket for each customer. It also describes an internally developed log-shipping tool that moves database backups to another location shortly after they become available.
The strongest statement is that all production customer data is stored at a minimum of two separate sites for disaster recovery. That is meaningful. It reduces dependence on one physical building and creates a route to recovery from destructive hardware or site failure. WiseTech says its continuity programme and supporting plans are reviewed and components tested at least annually.
But “two sites” is not a complete recovery specification. The report does not publish the interval between database backups, the maximum accepted data loss, the time needed to restore a large customer, the destination for each source region or whether the second copy is continuously queryable. “Shortly after backups are taken” describes replication timing relative to a backup; it does not disclose how often the backup itself occurs.
The distinction between durability and availability is critical. A customer's records can survive at another site while users remain unable to log in. A dedicated S3 bucket can preserve electronic documents while the CargoWise application or its authentication service is unavailable. A database copy can be intact while integrations queue, reject messages or require manual replay. Restoration can preserve yesterday's state without recreating the exact sequence of transactions that occurred immediately before failure.
The Alibaba Cloud exception makes the boundary especially visible. The SOC 3 says there is no site failover for Alibaba Cloud; availability is instead governed by the supplier contract and reviewed controls. That may be a rational design for country-specific environments, but it is not the same protection as a second active site. Customers assigned to China or Saudi Arabia should therefore ask what backup, export and rebuild path applies to their instance and whether a regional supplier outage has a workload-level remedy.
Disaster recovery is also different from continuity during a software fault. Replicating a corrupted database state or defective reference data to another location can reproduce the problem. A common authentication component can fail across hosted and self-managed environments. A release issue can affect multiple healthy sites at once. Geographic separation is powerful against local physical failure; it is much less effective against a shared logical cause.
WiseTech's public controls show that it understands these categories. Its information-security page describes annual continuity, disaster-recovery and crisis simulations alongside cyber exercises. The unanswered customer-level questions concern scope and outcome: which scenario was exercised for the customer's service, whether traffic actually moved, whether staff used the same communications path that would be available during a real incident, and whether recovery met the customer's operational deadline.
Transit diversity is an open question, not an absent capability
CargoWise cannot be used from South Africa unless a customer's office can reach the hosting environment. That path begins with a local access provider, crosses international and regional networks, enters a facility or cloud edge and reaches WiseTech's application. DNS, authentication and messaging services may take separate routes. Failure at any one of these layers can look to a user like “CargoWise is down”.
AS397950 does not reveal the current production path because it announces no routes. WiseTech may use provider-assigned addresses, other corporate autonomous systems, cloud addresses, content delivery services or facility transit under different network identities. The SOC 3 confirms network monitoring, firewalls and segmentation but does not name current transit carriers for Sydney, Chicago or Hamburg.
This is an evidence limit, not proof of single-homing. A large application operator can purchase diverse carriers without publishing BGP under its own ASN. Equinix colocation gives access to rich interconnection markets, and Aryaka's disclosed acceleration service can improve paths over the public internet. Neither fact proves that every customer domain has two physically diverse entrances or that South African access takes independent international routes.
For a South African customer, local resilience must be designed on both sides of the service. Two office links that share the same last-mile trench do not provide physical diversity. Two internet providers that converge on one upstream or cable system may fail together. A secondary access path is useful only if DNS, authentication policy, endpoint filtering and user devices allow it to reach the relevant CargoWise region.
The provider side deserves similarly precise questions. Does each core data centre have at least two contracted carriers? Do their fibre entrances use diverse ducts? Can inbound sessions be redirected without changing customer configuration? Are support and status channels hosted outside the affected production environment? Does a distributed denial-of-service event consume shared edge capacity before application traffic is separated?
Public records do not answer those questions. The correct network grade is therefore mixed: strong evidence of a mature hosted application and named facility/cloud dependencies, weak evidence for the present use of AS397950, and incomplete public evidence for carrier diversity. A procurement team should not convert that incompleteness into either a claim of resilience or a claim of fragility. It should ask for the current network diagram under confidentiality and test from the actual South African offices that will depend on the service.
Repair windows are where responsibility becomes visible
A hosted service reduces the customer's direct contact with failed hardware, but someone still has to repair it. In a WiseTech-managed building, WiseTech controls more of the intervention. In an Equinix facility, building staff control access and facility systems while WiseTech controls its tenant equipment. In a public cloud, the supplier replaces failed physical components and WiseTech works at the service and workload layer. Each model has a different restoration clock.
The SOC 3 says environmental protection devices, alarms and generators at WiseTech-managed sites receive periodic maintenance by providers or specialists. It says infrastructure changes pass through a change-approval process and emergency changes receive expedited review. For application changes, it describes release rings ranging from weekly to biannual delivery, with emergency changes still requiring approval.
These controls reduce improvisation. They also create windows in which capacity is deliberately removed from service or changed. A server being patched may need to restart. A switch replacement may move traffic to another path. A generator test can expose a latent transfer fault. A security update can be urgent enough to compress customer notice. The resilience question is whether the remaining environment holds the load and whether rollback is practical.
WiseTech's support material says customers can lodge incidents at any time through its eRequest system, with telephone escalation for severe outages. The SOC 3 is more specific: a complete outage or loss of an entire module without a manual workaround can be raised by phone, while other incidents use eRequest. That boundary matters during partial failure. If the application is degraded but the ticketing path remains available, users need to know which severity to choose and who can declare escalation.
Support availability is not identical to restoration time. A round-the-clock intake can acknowledge a problem while diagnosis, vendor escalation, hardware delivery or data repair takes much longer. If an Equinix cross-connect fails, WiseTech may depend on facility staff. If an Azure backup is needed, restore speed depends on configuration and volume. If a proprietary application defect is involved, only a limited engineering group may be able to correct it safely.
Hardware stock creates another hidden clock. The public documents do not state whether Chicago, Sydney and Hamburg hold compatible spare servers, storage controllers, optics and power supplies on site. Same-day delivery may be possible in a major city, but border controls, vendor shortages and security access can turn a replacement into a multi-day event. Cloud instances reduce that particular stock risk, yet they replace it with quotas, supplier capacity and service-specific recovery constraints.
A useful customer measure is therefore not “24/7 support” alone. It is time from detection to qualified ownership, time to a safe workaround, time to hardware or software remediation, and time to reconcile queued transactions. These intervals can be measured from incident records and exercises. Without them, a support number proves reachability of a team, not recoverability of the service.
June 2026 showed why another data centre is not always the answer
On 17 June 2026, logistics publication The Loadstar reported a CargoWise incident affecting customers globally. According to customer notifications seen by the publication, WiseTech activated a major-incident response after login problems. The report says remediation was implemented roughly two hours after escalation and describes disruption to electronic messaging.
The article also reports that hosted and self-managed customers were affected. An unnamed person familiar with the incident suggested a reference-data update caused login exceptions and that some customers restarted process controllers after a correction, but The Loadstar explicitly says WiseTech had not confirmed that cause. The incident itself is credible; the precise root cause should remain provisional unless WiseTech publishes a final account.
The event is analytically valuable because it cuts across the usual physical-redundancy story. If customers in multiple hosting models cannot log in, adding another powered rack does not necessarily help. The common dependency may sit in reference data, authentication, messaging, software distribution or another shared logical layer. A self-managed server can remain electrically healthy while a central service prevents effective use.
Customer accounts described sessions ending, inbound controlled messages being affected and routines needing to be replayed after recovery. Those reports do not establish the full global impact, but they illustrate the work that begins after the status changes from unavailable to available. Logistics systems exchange messages with many external parties. If an inbound message failed, duplicated or waited in another queue, a user may need to reconcile the business state rather than simply resume typing.
The incident does not invalidate WiseTech's multi-site design. It identifies a different failure class. Physical replication protects against site loss; release controls protect against defective changes; monitoring detects anomalous behaviour; operational procedures restore and reconcile service. All four are needed because no single control covers every cause.
It also makes independent communications important. A customer needs an incident channel that does not depend on the affected login path, a local decision-maker who can activate manual work, and a record of external messages that may need replay. In a South African office, time-zone alignment can help if regional support is staffed, but authority and technical access matter more than the telephone's country code.
One public user discussion about CargoWise cloud release timing alleges that WiseTech applied updates to hosted production environments in late 2025 and early 2026 with less control than some customers expected. This is an unofficial market signal, not verified incident documentation. It suggests that release-window expectations and customer control are active concerns. It cannot prove WiseTech's policy for every customer or that a particular update caused a service failure. The decisive evidence would be the customer's current agreement, release-ring assignment, update notices and change history.
South African data locality is a contractual question
South African presence can create an intuitive but incorrect assumption that South African customer data stays in the country. WiseTech's own public material points elsewhere. Its privacy help centre names Germany, the US and Australia as data-centre countries, and the SOC 3 names the main customer-domain locations without a South African site.
That does not automatically make the service unlawful for South African organisations. The Protection of Personal Information Act restricts transfers of personal information to foreign recipients but provides routes based on adequate protection, binding rules or agreements, consent and specified forms of necessity. South Africa's National Data and Cloud Policy adds a policy framework in which data sovereignty and sensitive government information receive particular attention. Sector and customer circumstances still need legal assessment.
WiseTech's 2026 DPA contemplates international transfers. It permits use of subprocessors, sets transfer mechanisms for several jurisdictions and says personal data may move to WiseTech and suppliers outside the originating jurisdiction. It also requires return or deletion of personal data at termination, at the controller's choice, unless law requires retention; if the customer does not exercise the return right within 60 days, WiseTech may delete the data.
That clause creates a legal exit right, not a complete technical migration plan. A usable exit needs defined export formats, complete document retrieval, database relationships, audit history, integration configurations and enough time and bandwidth to move the data. It also needs a receiving system that can interpret the export. A database copy that only CargoWise can read is different from a documented, testable business-data export.
Locality itself has several layers. The primary database may sit in Chicago or Hamburg. A disaster-recovery copy may sit in another region. Backups may be stored in Azure or Equinix infrastructure. Electronic documents may sit in AWS S3. Support staff may access records from another country. Logs, security telemetry and ticket attachments can have their own locations. Asking “where is our data?” should produce a matrix, not one city name.
WiseTech's disclosures help build that matrix, but they do not assign a region to a hypothetical South African customer. The customer must obtain the production and recovery locations in its order form or technical schedule, identify subprocessors that apply to the purchased modules and understand whether remote support access is possible. If the organisation handles customs, employee, consignee or customer information, it should map the categories and lawful transfer basis before deployment.
Data sovereignty is also operational. During an outage or termination, can the South African company obtain the records needed to continue moving goods and meeting regulatory duties? Does it maintain independent copies of essential documents and message histories? Can it produce a declaration or shipment record if the hosted service is unavailable? Jurisdiction matters, but so do export speed, file completeness and staff familiarity with the fallback.
Who feels the failure
CargoWise's importance is broader than the number of logged-in users. The platform covers forwarding, customs, warehouse, transport, carrier, parcel, accounting and document functions. A failure can therefore propagate through work queues and counterparties even when they are not WiseTech customers.
A freight forwarder may lose shipment visibility and the ability to update milestones. Customs teams may be unable to prepare or retrieve declaration data. Warehouse staff may lose task and inventory context. Finance teams may have delayed invoices or postings. Customers waiting for status messages may receive silence. Carriers and other partners may continue sending electronic messages that queue or fail. The physical cargo keeps moving, but the information needed to direct, clear and account for it can lag behind.
South African users face additional distance and connectivity considerations. If their assigned service sits in Germany, the US or Australia, international path quality affects latency and reachability. A local office outage can isolate users even while CargoWise remains healthy. Conversely, a global application fault can stop local work despite perfect Johannesburg connectivity. Diagnosis requires independent tests that separate office access, public routing, authentication, application health and integration queues.
The June 2026 incident indicates that self-managed deployment is not a complete escape. A company can own its server and still depend on WiseTech-controlled reference data, messaging or update mechanisms. Hosted and self-managed models distribute responsibility differently; neither makes the application independent of its vendor.
The risk grows as one global database replaces local systems. WiseTech's SEKO Logistics case study describes a migration from old self-managed servers to CargoWise Cloud and presents disaster recovery, security maintenance and hardware-cost reduction as benefits. Those benefits are plausible and valuable. The same consolidation means a fault in the central platform can affect many branches at once. Local spreadsheets and manual procedures become continuity tools rather than the primary operating system.
The practical goal is not to recreate the whole application offline. It is to identify the small set of transactions that cannot wait: critical customs work, cargo release, dangerous-goods information, warehouse dispatch, carrier messages and customer communications. Each needs a time-bounded manual method, a trusted local data extract and a controlled reconciliation step after recovery.
What a buyer should require before calling the service resilient
WiseTech's public material is stronger than that of many hosted-software companies. It names core locations and suppliers, describes backup and replication mechanisms, publishes a recent independent assurance report and acknowledges technology failure as an enterprise risk. That deserves weight. It should also make the remaining questions easier to specify.
First, identify the exact service. CargoWise Cloud, a customer private cloud and a self-managed installation do not share the same responsibility boundary. The agreement should state which party owns the operating system, database, backup, network edge, endpoint client and integration components.
Second, name the production and recovery locations for the customer domain. “Global data network” is not enough for data-transfer assessment or latency planning. The customer should know the primary country, recovery country, backup services and document-storage region, with notice obligations for material changes.
Third, obtain recovery objectives and recent measured results. A site count is useful only when paired with maximum accepted data loss, target restoration time, tested workload and any assumptions about supplier availability. The result should distinguish restoration of login, database consistency, messaging and external integration.
Fourth, examine usable capacity under failure. The provider should be able to explain whether the recovery site is pre-provisioned, how many simultaneous customer recoveries it supports, how restoration is prioritised and what happens when demand exceeds reserved headroom. Exact server counts are less important than a credible capacity model.
Fifth, test route diversity from the real offices. South African users should exercise a secondary connection and confirm that authentication, endpoint controls and DNS permit access. WiseTech should explain carrier and facility diversity at the assigned hosting region under appropriate confidentiality. AS397950 should not be accepted as evidence because it is not currently routed.
Sixth, document maintenance authority. Customers need the applicable release ring, notice policy, emergency-change rule, rollback method and freeze periods around operational peaks. Unofficial complaints about update timing can be settled only by the current contract and change records.
Seventh, verify support escalation. The Africa number and 24/7 intake are valuable, but named customer roles should know when to call, how severity is assigned, how updates are delivered when the application is inaccessible and who can authorise a workaround. Response and restoration metrics should be reviewed separately.
Eighth, test data exit before it is needed. Export a representative set of records and documents, load it into an independent environment and measure completeness, time and cost. Confirm how deletion, legal retention and backup expiry work after termination. A contractual right that has never been exercised is an unmeasured dependency.
Finally, maintain a local continuity pack that does not depend on the same login or network. It should contain current contacts, essential operating data, message-reconciliation procedures and authority to switch into degraded mode. The pack should be small enough to remain current and realistic enough to exercise.
A mature service with a visible physical underside
WiseTech Global's hosted proposition is real and substantial. CargoWise is not a brochure assembled around an idle network number. A recent assurance report identifies a multi-region estate, specific facilities, cloud suppliers, backup services, dedicated document buckets, replication and annual continuity work. Financial disclosures show a large recurring software business capable of sustained infrastructure investment.
The evidence also imposes limits. AS397950 is a US registration with historical routing, not a current South African delivery network. The Johannesburg office and South African subsidiaries establish local corporate reach, not local data residency. Multiple sites establish geographic options, not automatic failover or unlimited spare capacity. Replicated data establishes recoverability, not immediate application availability. Round-the-clock support establishes an incident door, not a guaranteed repair time.
The June 2026 disruption brings those distinctions together. Healthy racks in several countries could not, by themselves, prevent a shared application problem from interrupting work. Recovery involved fixing the common cause and reconciling messaging after users returned. That is the practical meaning of cloud dependence: physical resilience and software resilience must hold at the same time.
For South African customers, the best reading is neither alarmist nor complacent. WiseTech publishes enough to support confidence that CargoWise is operated as serious infrastructure. It does not publish enough to let a customer outsource every resilience judgment. The customer still has to pin down its assigned region, recovery path, transfer basis, maintenance authority, support escalation and exit method.
Hosted capacity is valuable precisely because one provider can manage more equipment, specialists and recovery work than each logistics company could justify alone. The bargain remains sound only when the abstraction is tested against its physical underside: powered racks, diverse paths, stocked components, controlled releases and people able to restore the service within the business's real deadline.