Stratus Cloud Technologies sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Stratus Cloud Technologies publicly offers cloud migration, hosted servers, storage, backup, remote access, on-premises management, business voice and virtual technology leadership. The breadth is clear; the physical sites, platform design, installed capacity and service levels behind it are not publicly specified.
• ARIN records assign Stratus AS18935, the IPv4 block 23.149.216.0/24 and the IPv6 block 2602:fa96::/36. The company website resolved to 23.149.216.230 when checked, providing a direct sign that at least one public service uses company-registered address space.
• RIPEstat showed AS18935 announcing no IPv4 or IPv6 space on July 12, 2026. Both registered blocks were instead visible with AS401998 as origin. Routing history shows a transition beginning in November 2025. That is evidence of a changed operating boundary, not proof of any ownership, outsourcing or corporate relationship.
• The present origin was widely visible and the IPv4 and IPv6 routes validated under RPKI. Those are useful reachability and route-authorisation signals, but they do not establish data-centre diversity, spare capacity, backup integrity, support depth or a tested migration path.
• The network evidence grade is Medium, while confidence in the full customer-service operating model is Weak. A live website and active routes support continuing operation at the public edge, but Stratus publishes too little about facilities, cloud suppliers, recovery sites, support cover and data portability to treat its broader resilience claims as verified.

The cloud claim begins at a specific address

The most useful fact about Stratus Cloud Technologies is not the word cloud in its name. It is the address 23.149.216.230. In a July 2026 check, the company's domain, stratustech.cloud, resolved to that IPv4 address. The address falls inside 23.149.216.0/24, a block that the ARIN registration assigns to Stratus Cloud Technologies. The site responded over HTTPS and described hosted servers, storage and backup among the company's services. That combination provides a modest but meaningful operating signal: a public Stratus service is running on Stratus-registered address space.

It does not reveal what sits behind the address. A web server can be a physical machine, a virtual machine, a reverse proxy or a container. It can be located in a rack controlled by Stratus, in leased colocation space, or on infrastructure administered by another provider. It can share its facility with customer workloads or be completely separate from them. An address proves a routeable endpoint, not a data hall, a server count or a recovery architecture.

That distinction matters because the company's cloud page makes a wider promise. Stratus says it designs, migrates and manages cloud environments sized to a customer's business. It lists cloud migration planning, hosted servers, storage, backup, secure remote access, monitoring, support and scaling. Each item has a physical and contractual dependency. Hosted servers need processors, memory, power and replacement parts. Storage needs media, controllers, replication and integrity checks. Backup needs a separate failure domain and a tested restore procedure. Remote access needs identity systems, reachable networks and support when credentials fail.

The service may be delivered well. The public material simply does not say enough to establish how. There is no published inventory of cloud regions or facilities, no stated hypervisor or storage design, no indication of whether capacity is owned or resold, and no public description of recovery objectives. Buyers therefore need to read the service claim as the start of due diligence, not the end of it.

A regional managed-service bundle, not a disclosed hyperscale cloud

Stratus describes a broad business-technology practice. Its home page says it supports at-home businesses and multi-location companies, provides telephone and infrastructure needs, and acts as an extension of customer staff. Alongside cloud computing, it advertises on-premises management, HD Voice and a virtual chief information officer service. The contact details point to the Myrtle Beach area in South Carolina, while ARIN lists the registrant in nearby Murrells Inlet.

This looks more like a regional managed-service bundle than a self-contained public cloud with documented regions and standard instance types. That is an interpretation of the published offer, not a claim about the company's undisclosed contracts. A managed provider can combine its own servers, rented racks, wholesale voice, software licences and third-party cloud services behind one customer relationship. For a small or medium-sized business, that can be more useful than buying each component separately. It gives the customer one team that understands the office network as well as the hosted workload.

The same arrangement concentrates dependency. If Stratus is both adviser and operator, it may choose the architecture, hold administrator credentials, manage licences, receive monitoring alerts and control the first support response. If it also supplies voice and remote access, a failure can affect both the customer's applications and the channel used to ask for help. A buyer needs a clear map of which components Stratus operates directly, which it manages on the customer's premises and which depend on an upstream supplier.

The company's on-premises management page promises server and network administration, hardware procurement, setup, patching, monitoring and support. Its virtual CIO page adds planning, budgeting, vendor management, security guidance and regular reviews. These services bring human judgment into the infrastructure boundary. Resilience then depends not only on available machines but also on documentation, credential custody, staffing, change approval and the ability of another qualified person to take over.

There is no reason to treat a regional provider as inherently less reliable than a large one. Smaller operators can be attentive, technically capable and fast to act. But personal service is not a substitute for evidence. The relevant questions are whether responsibilities are named, whether alternatives are truly independent, whether recovery is exercised, and whether the customer can continue if one individual, supplier or site becomes unavailable.

Registered resources and routed resources have diverged

ARIN's AS18935 record names Stratus Cloud Technologies as the registrant and dates the current registration to March 14, 2023. It also records office-hours network operations coverage as Monday to Friday, 9am to 5pm Eastern, and gives the same main telephone number shown on the company website. Separate ARIN records assign the company 23.149.216.0/24 and 2602:fa96::/36.

Those records establish administrative control over number resources at the registry layer. They do not establish that AS18935 is the current route origin. On July 12, RIPEstat's AS overview marked AS18935 as not announced. Its routing-status view showed zero announced IPv4 and IPv6 space and no observed neighbours. The last route it recorded from AS18935 was 23.149.216.0/24 on December 5, 2025.

Current network information pointed elsewhere. RIPEstat associated 23.149.216.0/24 and 2602:fa96::/36 with AS401998. That ASN is registered to a separately named Myrtle Beach organisation. Public routing data cannot by itself tell us the commercial or operational agreement that permits the routes, and it would be wrong to infer a corporate relationship from adjacency, geography or routing alone.

What can be said is narrower. Stratus remains the registered holder of the address blocks. The blocks are visible on the internet. Their current origin is not Stratus's AS18935. The Stratus website is reachable inside the IPv4 block. Someone has also configured route-origin authorisations that make the current AS401998 origin valid under RPKI. These facts indicate continued use alongside a changed control-plane arrangement.

For customers, the unanswered question is who can act during a fault. Who controls the edge routers? Who can change a route policy, contact transit providers or withdraw a bad announcement? Who owns the cross-connect and colocation ticket? Does Stratus have direct access, or must it escalate through the origin network? A registry record names the resource holder; it does not answer the repair chain.

The November 2025 transition is a resilience clue

The routing history for 23.149.216.0/24 shows AS18935 originating the exact /24 from April 2023. AS401998 first appears as an origin in the interval beginning November 8, 2025. Both origins were visible during part of the transition, and AS401998 remained the observed origin through July 12, 2026. The IPv6 history shows the same broad pattern for the /36.

An origin change can have many legitimate causes. A provider may consolidate routing, move facilities, change transit arrangements, outsource edge operation, merge network functions or redesign its resilience. The change could be temporary or permanent. Public route collectors show what paths they observed; they do not record the contract, rack move or engineering decision behind those paths.

The transition matters because it is a naturally occurring test of operational control. Customers should ask whether workloads moved, whether only BGP changed, and whether addresses remained stable. They should ask whether service was interrupted and whether any customer action was required. They should also ask what failure the new arrangement is intended to survive. If the move improved resilience, Stratus should be able to explain the new separation of routers, carriers, sites and support responsibility without disclosing sensitive configuration.

There is an encouraging control-plane signal. RIPEstat returned a valid result for the AS401998 origin of both the IPv4 route and the IPv6 route. That means the observed origin matched a published Route Origin Authorisation at the time of the check. It reduces one class of routing error for networks that enforce origin validation.

RPKI does not prove the new origin has spare bandwidth, diverse fibre or authority to repair customer servers. It says the route origin is authorised, not that every dependency behind the route is resilient. A valid route can still lead to an overloaded port, a failed firewall, a powerless rack or a server waiting for parts.

Two visible upstream paths do not yet prove diversity

The active origin's routing-status data showed two IPv4 prefixes, two IPv6 prefixes and visibility from nearly all reporting RIPE RIS peers on July 12. Its neighbour view showed AS174 and AS6939 on the left side of observed paths. Those ASNs are widely known transit networks, but the observation should not be promoted into a claim about Stratus's contracts.

Public BGP adjacency can support a working hypothesis of more than one external path. It cannot show whether both paths carry full traffic, whether each is large enough for peak load, or whether they enter through different conduits. Two sessions can terminate on one router. Two carriers can share one building entrance. A primary and backup path can use the same long-haul segment. A nominally independent route can be limited by a small emergency commit that congests as soon as traffic shifts.

This is why transit diversity has four layers. There must be logical diversity, so routing policy can select another path. There must be supplier diversity, so one carrier's commercial or operational failure does not remove both options. There must be physical diversity, so cables, entrances, meet-me rooms, routers and power do not share a single point of failure. Finally, there must be capacity diversity: the surviving route must carry the required workload during the busiest relevant period.

Neither AS18935 nor AS401998 returned a public network entry from the PeeringDB query for Stratus or the query for the current origin. Absence from that voluntary directory is not evidence of absence from a facility or exchange. It does mean there is no operator-published PeeringDB profile to cross-check facility presence, exchange connections, traffic levels or peering policy.

A prospective customer should therefore ask for a simple failure demonstration. What happens if the primary upstream is disconnected? Does traffic reconverge without changing customer addresses? What percentage of normal peak load can the remaining path carry? Are inbound and outbound paths both tested? Does monitoring remain reachable through an independent channel? A diagram is useful, but a dated test result is much stronger.

Location is still an unanswered engineering question

Stratus has a clear regional identity, but the public addresses associated with the company are contact locations, not disclosed data centres. ARIN lists a street address in Murrells Inlet. The company site lists a post-office box in Myrtle Beach. Neither should be treated as the location of a customer rack. A corporate address tells readers where an organisation can be contacted; it does not establish where data is stored or where hardware is operated.

The website does not name a facility, city pair, availability zone or cloud region for hosted servers and storage. It also does not say whether backups are kept in the same building, another South Carolina site, another US region or a third-party cloud. This leaves both physical resilience and data locality unresolved.

Cloud services often create a useful sense of location independence. NIST's definition of cloud computing describes pooled resources, broad network access, rapid elasticity and measured service. It also notes that customers may not know the exact location of physical resources even when they can select a higher-level location such as a country, state or data centre. That abstraction is efficient, but it does not remove location risk.

A customer needs a placement schedule rather than a country label. It should identify where production data, replicas, backups, logs, account records and support tickets reside. It should name the legal entity responsible for each layer and the subcontractors that can access it. It should explain whether remote administrators work from other jurisdictions. If locality is a compliance or latency requirement, the agreement should state what can move, who approves the move and how the customer is notified.

The current routing evidence cannot locate the racks. An IP geolocation result would not settle the question either; databases often represent registration, inferred network position or a service edge rather than the precise place where data is stored. Facility confirmation requires operator disclosure, contract language or direct technical evidence.

Installed capacity is not usable capacity

Stratus says it sizes cloud environments to a customer's business and provides ongoing scaling. The economic value is straightforward: customers avoid buying every server for the largest imaginable peak, while the provider pools equipment and expertise. But the word scaling can conceal the difference between capacity that exists on paper and capacity available during a fault.

Installed capacity includes processors, memory, disks, network ports, addresses, transit commits, software licences and support hours. Usable capacity is what a customer can actually consume after normal overhead and safety margins. Resilient capacity is what remains after the largest credible component failure. Recoverable capacity is what can be restored within the customer's deadline using available people, parts, data and access.

Public records support only a narrow view. Stratus has one registered IPv4 /24, a large IPv6 allocation and a live web endpoint. Those numbers do not disclose compute or storage. An IPv4 /24 can address many virtual services through translation, or very few systems with generous allocation. An IPv6 /36 provides an enormous logical address space but says nothing about powered servers. Address capacity and workload capacity are different units.

A buyer should request figures that survive a failure scenario. How many hosts can be lost before service is oversubscribed? How much storage remains after replication and reserved headroom? Can all protected workloads restart at the recovery site, or only a priority subset? Is the backup network sized for a full restore, or only for daily increments? What happens to performance while a failed disk group rebuilds?

There is also human capacity. Monitoring and scaling require people who can interpret alarms, approve changes and communicate with customers. A small team may manage normal operation efficiently but become saturated during a regional outage or a mass patching event. The service review should include simultaneous-incident assumptions, not only device redundancy.

Racks, power and spare parts set the repair clock

Every hosted server eventually depends on a chassis in a rack. That rack depends on power distribution, cooling, structured cabling, a network edge and controlled physical access. If Stratus leases space, the facility operator may control generators, cooling and remote hands. If it buys capacity from another cloud provider, that provider controls even more of the physical layer. In either case, the customer-facing service level can be no stronger than the combined chain.

The most important facility questions are concrete. Does production use one rack or several? Are replicas in a different power domain? Are network devices dual-powered? Do fibre paths enter separately? How long can batteries and generators support the relevant load, and when were transfers last tested under load? Which failures require a facility ticket rather than action by Stratus staff?

Hardware stock matters just as much. A redundant design can still miss its recovery objective if the replacement router, storage controller or server is hours away. The customer should ask which components are stocked on site, which are covered by vendor replacement contracts and which require procurement after failure. It should distinguish a spare that is physically present from a part that a supplier merely promises to ship.

The company's on-premises offer makes this question especially relevant. Stratus says it procures and sets up customer hardware as well as managing servers and networks. That can give it valuable knowledge of the entire path from office to hosted service. It also means restoration may cross property boundaries: customer premises, carrier access, Stratus-managed systems and a hosting facility. The incident owner must know which party can act at each boundary.

Repair windows are not just contractual response times. The clock includes detection, triage, authorisation, travel or remote-hands queueing, access approval, part availability, replacement, configuration, validation and customer communication. A four-hour part replacement can become a much longer outage if the alarm is noticed late or the correct person cannot enter the room.

Support coverage is part of the infrastructure

Stratus emphasises personal support. Its website says staff become an extension of the customer's team. That is a meaningful proposition for businesses without deep internal IT staffing. It also raises the standard for escalation clarity: when the external team becomes part of operations, the customer must know when and how that team is available.

The ARIN record for AS18935 lists network operations hours as Monday to Friday, 9am to 5pm Eastern. Registry comments can be stale or limited to a particular contact function, so they should not be read as a definitive support schedule. Still, no public Stratus page reviewed for this article states round-the-clock cloud or voice escalation, a severity matrix, response targets or an independent status channel.

This absence does not prove that after-hours support is unavailable. It means the customer should obtain it in writing. The agreement should say which incidents qualify for telephone escalation, how quickly a qualified engineer acknowledges them, who can declare a major incident and how an unresolved case moves to a senior owner. It should also explain how Stratus contacts any facility, transit, hardware or software supplier on the customer's behalf.

Support channels need their own redundancy. If the hosted environment runs the ticket portal, identity provider and phone system, a common failure can remove the means of reporting it. Customers should retain an out-of-band telephone number, named contacts and offline copies of key procedures. Stratus should be able to publish incident notices independently of the affected production stack.

The breadth of the offer increases the chance of correlated demand. A severe weather event on the South Carolina coast could affect power, access networks, customer premises and staff availability at once. The relevant staffing question is not whether one ticket can be handled quickly on a normal day. It is whether the provider can prioritise many customers, communicate honestly and obtain physical access during the same disruptive event.

Backup is a recovery claim, not a storage feature

Stratus explicitly includes backup on its cloud page. That is valuable because backup is often the last line of defence against deletion, corruption, ransomware and platform failure. But a backup becomes useful only when it is complete, isolated enough to survive the original failure and restorable within the customer's deadline.

The public site does not describe backup frequency, retention, immutability, encryption, storage location or restore objectives. It does not say whether backups are included with every hosted server or offered separately. It also does not specify whether Stratus can restore an entire environment, individual files, application-consistent databases or configuration and identity data.

CISA's ransomware guidance recommends offline, encrypted backups and regular tests of availability and integrity in a disaster-recovery scenario. NIST's contingency-planning guidance treats recovery as a coordinated combination of plans, procedures, alternate equipment and alternate locations. Both point to the same practical conclusion: replication is not enough, and possession of backup data is not the same as demonstrated recovery.

A Stratus customer should test three restores. The first is a routine file or mailbox recovery, which shows that ordinary requests work. The second is a complete application restore into an isolated environment, including dependencies, credentials and network rules. The third is a provider-failure exercise: can the customer obtain data and rebuild elsewhere if the normal Stratus console or support path is unavailable?

The test should record recovery-point and recovery-time results. It should also measure transfer speed. A complete backup can still be operationally useless if exporting or restoring it takes days longer than the business can tolerate. For large data sets, the constraint may be bandwidth, read performance, egress fees or the time required for a provider to prepare an export.

Voice makes power and access failures more consequential

The Stratus HD Voice page offers business calling, voicemail, auto-attendant, call routing and support across mobile and multiple locations. That service can improve continuity when employees move between offices and remote work. It can also couple telephony to internet access, local power, hosted call control, number-porting arrangements and emergency-calling configuration.

The FCC has repeatedly treated backup power as important to continuity of IP-based voice and access to emergency services. In its 2015 backup-power order, the commission focused on maintaining essential communications during commercial power failure. A business deployment has additional dependencies: powered handsets or adapters, switches, routers, broadband circuits and any session controller or hosted voice platform.

Customers should ask whether Stratus is the underlying voice carrier, a reseller or the managed contact for another provider. They should document who owns telephone numbers, how quickly numbers can be ported, where emergency addresses are maintained and which features remain available if the customer's primary internet connection fails. A mobile application is useful only if authentication and call control remain reachable.

Voice also changes incident communications. If the same provider manages the office network, remote access and telephony, a single configuration error or account suspension can affect several channels. The customer needs an independent way to contact Stratus and an independent way to reach staff, suppliers and emergency services.

The public offer contains no claim of an outage, and none should be inferred. The point is architectural: combining services can simplify support while increasing the impact of a shared failure. The contract should identify those shared components and the tested alternatives.

Billing and identity can stop service without a hardware fault

Infrastructure failure is not always electrical or mechanical. A card expiry, disputed invoice, licence lapse, domain renewal problem or administrative lock can interrupt service while every server remains healthy. Managed-service bundles are particularly exposed because one commercial account may govern cloud, backup, remote access, security software and voice.

Stratus's terms and privacy policy were updated in July 2026, but the public terms focus on account security and SMS verification rather than a cloud service level. They state that services are provided as available, disclaim warranties and limit liability, while the privacy policy describes account information, authentication data, support and an SMS provider. These pages provide evidence of an active account-security process; they do not publish service credits, data-return commitments or a detailed hosted-service suspension policy.

Customers need the commercial failure path in writing. How much notice precedes suspension? Are critical voice or backup services treated differently? Can a disputed amount disable unrelated services? Who can authorise emergency reinstatement outside office hours? Are customer domains, certificates and licences registered in the customer's own name where practical?

Credential custody deserves the same attention. Stratus may need privileged access to administer cloud and on-premises systems. The customer should maintain an inventory of those accounts, require individual authentication, retain emergency access under its own control and ensure that departures do not leave undocumented credentials behind. Logs should be exportable to a customer-controlled location so they remain available during a provider dispute or security investigation.

The US Federal Trade Commission's service-provider guidance advises businesses to ask how providers secure data, who can access it and how staff are trained. Those questions apply to operational continuity as well as privacy. A provider cannot restore what it cannot securely administer, and a customer cannot govern a service it cannot independently observe.

Data locality has to cover replicas, logs and support

The Overview identifies the service area as the United States, consistent with the company's contact details and ARIN registrations. That is not a guarantee that every customer byte remains in the United States, much less in South Carolina. A managed cloud environment can use third-party storage, security, monitoring, messaging and support services in several locations.

Data locality should therefore be defined by data class. Production databases may sit in one place, backups in another, logs in a third and support records in a fourth. Authentication messages may pass through an SMS supplier. Voice records may be held by an underlying carrier. Each copy has different retention, access and deletion rules.

The Stratus privacy policy says service providers may process information on the company's behalf and specifically mentions an SMS delivery provider. That is ordinary disclosure, but it illustrates the broader point: even a seemingly simple account-security function crosses a supplier boundary. Hosted-service buyers should obtain the complete relevant subcontractor list and notification terms for changes.

A robust locality schedule should answer five questions. Where is each data class normally stored? Where can it move during recovery? Who can access it remotely? Which law and contract govern that access? How is deletion verified after migration or termination? The answer should cover metadata and logs, not only primary files.

Locality also affects latency and incident response. A backup in a distant region may survive a local disaster but take longer to restore. A nearby replica may be fast but share the same storm, power market or fibre corridor. Resilience requires deliberate separation, not maximum distance or minimum distance by itself.

Migration is the test of whether the customer owns an exit

Stratus sells migration into managed cloud environments. The harder resilience question is migration out. A customer that cannot retrieve data, configuration, logs and identity records in usable forms is dependent not only on the current service but also on the provider's willingness and ability to help during an exit.

NIST's cloud synopsis identifies network dependence and portability limits as recurring cloud concerns. A 2025 GAO review of private-sector cloud practices likewise describes data portability and application compatibility as important ways to manage lock-in, while noting that multi-cloud designs add complexity and cost. These are not arguments against managed cloud. They are reasons to price the exit path before it is urgently needed.

The customer should know which exports are self-service, which require Stratus and which require an upstream supplier. It should specify formats, encryption, delivery method, fees and expected preparation time. A virtual-machine image alone may omit firewall policy, DNS, certificates, monitoring, backup history and service accounts. A database dump may omit files, attachments or audit records.

Address continuity is another issue. Customers using provider-assigned addresses will usually need DNS changes or other migration steps when moving. The Stratus /24 is company-registered space, but public evidence does not show whether customer services receive addresses from it or whether any addresses are portable by contract. Buyers should not assume they can take an address merely because it appears on their service.

An exit exercise does not require abandoning the provider. One small, representative workload can be exported and rebuilt elsewhere each year. The result reveals missing documentation, incompatible formats, unknown licences and transfer bottlenecks while there is time to fix them. A provider willing to support such a test is demonstrating operational confidence.

The economics depend on the hidden denominator

Stratus's IT spending page offers cost and usage review, comparison of cloud and on-premises options, licence right-sizing and recommendations. This is a sensible service for businesses that may otherwise buy too much hardware or accumulate unused subscriptions. Shared infrastructure can replace large capital purchases with more flexible operating costs.

The comparison is only useful if it uses the same resilience standard on both sides. An on-premises server with no second site should not be compared with a premium replicated cloud service as though they are identical. Conversely, a low monthly hosted price should not be treated as equivalent to local infrastructure if backup, after-hours support, data export or recovery capacity costs extra.

The hidden denominator is recoverable service. Customers should calculate cost per protected workload, not simply cost per virtual processor or gigabyte. The calculation should include backup retention, restore tests, bandwidth, licences, support, security monitoring, migration assistance and the capacity reserved for failure conditions. It should also include the customer's own work: application remediation, vendor management and testing do not disappear when servers move.

Billing design can encourage or discourage resilience. Charges for backup retrieval, cross-region traffic or data export may be justified by real costs, but they can make customers avoid tests. A well-designed agreement gives customers enough included recovery activity to verify that the service works. Untested protection is a cheap line item until the day it is needed.

Stratus's regional, combined offer may have an economic advantage if one team can manage office hardware, connectivity, cloud and voice coherently. The value depends on whether that integration reduces handoff delays without creating an undocumented single point of control. The customer should pay for accountable coordination while retaining independent records and exits.

Six failures a customer should rehearse

The first scenario is loss of the current route origin. Assume AS401998 stops announcing the Stratus IPv4 and IPv6 blocks. Does AS18935 resume origin, does another authorised network take over, or must services move to new addresses? The November 2025 transition suggests the routing arrangement can change; a customer needs to know whether a reversal or alternate origin is prepared and tested.

The second is loss of one external path. Remove the connection represented through AS174 or AS6939 and observe traffic, latency and packet loss. The exercise should confirm that the surviving path has enough capacity, that return routes remain sensible and that monitoring sees the event. It should also establish whether both routes are physically independent.

The third is a rack or facility failure. Shut down a host, storage component or simulated site and restore a protected application elsewhere. Measure the actual recovery point and recovery time. Verify that DNS, certificates, identity, firewall rules and monitoring move with the workload. If no second site exists, document the alternative equipment and access plan honestly.

The fourth is a destructive account compromise. Assume privileged credentials and online backups are affected. Restore from an isolated copy using emergency identities. CISA's guidance is relevant here because attackers often seek accessible backups. The test should prove that recovery credentials, encryption keys and clean software are available outside the compromised environment.

The fifth is loss of support and billing systems. Disable the normal portal, primary phone service and a key staff account. Can the customer reach a qualified responder, prove entitlement and prevent automated suspension? Can Stratus communicate status without relying on the failed system? This scenario tests administration as infrastructure.

The sixth is provider exit. Produce a complete export, rebuild a representative service elsewhere, port a test number where possible and rotate provider-held credentials. The aim is not to predict Stratus failure. It is to make the customer's continuity independent of any single supplier's continued health.

What would raise confidence

The public evidence supports a live regional operator at the network edge. The website is current, the contact details align with ARIN, the site sits in company-registered IPv4 space, the IPv4 and IPv6 routes are visible, and their current origin is RPKI-valid. Those are stronger signals than a dormant brand with only a registry entry.

Confidence would rise materially with a short infrastructure statement. It could name the production and recovery metros, distinguish owned equipment from leased or upstream cloud capacity, describe physical and transit diversity, and state whether customer workloads use the registered address blocks. It would not need to reveal rack numbers, router configurations or sensitive supplier terms.

A service-level schedule would settle the human boundary. It should define support hours, severity levels, after-hours escalation, incident communication, planned maintenance and supplier escalation. A backup schedule should define retention, isolation, recovery objectives and test frequency. A portability schedule should define export formats, preparation time, fees and assistance after termination.

The current origin arrangement deserves a direct explanation to customers. Stratus could state who operates AS401998 for the relevant routes, what responsibility Stratus retains, and how routing recovers if that operator or relationship fails. Public BGP already exposes the origin; explaining the support boundary would reduce uncertainty without weakening security.

Independent evidence would be stronger still: dated failover results, sampled restore records, evidence of generator and UPS tests, and customer-specific exit exercises. Certifications can help with process, but they should not replace the operational tests relevant to the actual service.

A medium network grade, and a weak operating-model grade

Stratus Cloud Technologies is not merely a name in an address registry. Its website is active on 23.149.216.230, inside its ARIN-registered /24. Its IPv4 and IPv6 blocks are publicly routed, broadly visible through the current origin and valid under route-origin validation. The company also publishes a coherent set of services for cloud, on-premises systems, business voice and technology management.

The evidence stops before the most expensive questions. AS18935 is not currently announcing space. The registered blocks now originate through AS401998, and the reason and support boundary are not publicly explained. There is no public facility list, capacity statement, platform architecture, recovery-site description, service level, restore result or migration commitment. PeeringDB provides no profile for either ASN. The website's general terms do not fill those gaps.

That produces two different assessments. The network evidence grade is Medium: number-resource ownership, a live endpoint, route history, current visibility and RPKI status form a credible, cross-checkable operating surface. Confidence in the full customer-service operating model is Weak: the physical and contractual chain behind hosted servers, storage, backup, voice and support remains largely undisclosed.

For customers, the conclusion is practical rather than accusatory. Treat the active site and routes as evidence that there is something real to test. Then test the parts that the cloud label hides: rack and power separation, surviving transit capacity, spare hardware, after-hours authority, clean restores, billing continuity and a complete exit. Stratus sells the convenience of one accountable technology partner. The resilience of that promise depends on whether accountability continues across every supplier, facility and repair window behind it.