Mark Anthony Constable for Spiderweb Cloud and sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Mark Anthony Constable is not an empty label in a network database. The Australian ABN Lookup record for ABN 69 851 855 459 names CONSTABLE, MARK ANTHONY as an active individual or sole trader from 1 September 2004, with business names including RentaNet and Spiderweb Cloud.
• The current commercial surface is real but small. Spiderweb sells WordPress and email hosting, a pay-as-you-grow plan, web design and Linux support, while RentaNET advertises managed Linux servers, container-like plans, Proxmox cluster management, BinaryLane-based options, Australian support hours and yearly pricing.
• APNIC records AS153475 as SPIDERWEBCLOUD-AS-AP with the description "Mark Anthony Constable for Spiderweb Cloud and" and "RentaNet offering Email and Web hosting services." RIPEstat, however, showed AS153475 as not announced on 12 July 2026, with zero observed prefixes and zero observed neighbours.
• APNIC also attaches two active portable IPv4 blocks, 203.25.132.0/24 and 203.25.238.0/24, to Spiderweb Cloud. Both were globally visible in RIPEstat on 12 July 2026, but both were originated by Mammoth Media's AS133159 rather than by AS153475.
• The network evidence grade is Medium with an explicit independence downgrade. There is good public evidence of a current Australian sole-trader hosting operation and routed address space, but public evidence does not prove Spiderweb-controlled rack placement, physical transit diversity, route-origin authorisation, multi-site recovery, backup restorability or customer exit capacity.

A small host can be real without owning the whole chain

The strongest reading of the public record is not that Spiderweb is a phantom network. It is that the customer-facing service and the network-control story sit at different levels of the stack. The ABN Lookup record for ABN 69 851 855 459 names CONSTABLE, MARK ANTHONY, shows an active status from 1 September 2004, gives the entity type as individual or sole trader, and lists the business names MOTD, Spiderweb Cloud, Digital Mail Service and RentaNet. The same record places the main business location in Queensland 4218 and says the GST status is not currently registered.

That legal record matches the service names on the public sites. Spiderweb's home page offers WordPress hosting, email hosting, website design and Linux support, gives a Broadbeach postal address and displays the same ABN. RentaNET's services page describes managed Linux servers, server administration, security hardening, mail server components, Proxmox cluster management and support. The service is visibly current enough to include a 2026 footer and live customer portal links.

The important caveat is that a live small host does not automatically own every physical or network element beneath the customer service. A WordPress mailbox, managed server or container plan is a bundle of dependencies. Someone owns or leases the compute. Someone controls the data-centre cabinet or cloud account. Someone operates upstream routing, storage, backup media, DNS, mail queues, billing, support access and emergency credentials. The brand that answers the phone can be responsible to the customer while relying on third-party facilities and transit.

That boundary is common in managed hosting, and it is not a defect by itself. In fact, using a specialist Australian infrastructure supplier can be more resilient than trying to run everything alone. But the boundary has to be visible. Customers need to know whether the service is backed by Spiderweb-owned portable address space, provider-assigned addresses, BinaryLane infrastructure, Cloudflare caching, another VPS supplier or some mixture. They also need to know which party can act when an outage requires a route change, storage restore, host replacement, data export or refund.

This article therefore treats Spiderweb and RentaNET as a current Australian hosting operation but not as a proven independent network operator. That distinction matters because the first claim is well supported by business and service evidence, while the second is not supported by current public routing for AS153475.

The public offer is hosting, mail and managed support

Spiderweb's offer is explicitly customer-facing. The main Spiderweb page says the company provides secure, cost-effective WordPress and email hosting for personal or business domains, along with web design services and support by phone, SMS or email. It says customer websites come with WordPress pre-installed and that WordPress installations, plugins and themes are updated weekly. It also states that optional worldwide delivery support can be provided through Cloudflare while origin web servers are optimised with nginx and PHP-FPM.

The mail service is equally concrete. Spiderweb publishes IMAP settings for mail.spiderweb.com.au, with port 993 over SSL for incoming mail and port 465 over SSL for outgoing mail. The same page says the secure IMAP service includes a personalised spam filter and supports SPF, DKIM, DMARC and DNSSEC. It also says Spiderweb intends to disable POP email service by the end of 2025, which makes IMAP not only a support preference but a migration requirement for older customers.

The pricing page gives a low-end economics model. The pay-as-you-grow plan starts at AUD20 per year for 1 GB of storage, then prices WordPress websites, IMAP mailboxes and additional storage in small increments. The page gives examples of AUD60 per year for one WordPress site, one mailbox and 1 GB of storage, AUD90 per year for a second website and domain, and AUD112 per year for a heavier 10 GB setup. It also states that domain registration is billed separately and that the plan includes unmetered bandwidth for normal web and mail traffic, with abusive traffic trends potentially leading to suspension.

That pricing tells the buyer a lot about the operating model. This is not a hyperscale cloud posture. It is a support-heavy, small-account hosting model where the customer pays for a managed online presence, not raw access to a large resource pool. A provider can run this well if it keeps careful control of mail queues, backups, spam filtering, storage allocation and support contact. It can also become fragile if too many functions converge on one server or one support person.

RentaNET extends the same footprint into managed server capacity. The RentaNET pricing page lists plans with 1 to 4 vCPU, 1 to 8 GB RAM and 10 to 80 GB NVMe, billed annually from AUD79 to AUD419. It says each plan includes web, mail, DNS, CMS and personal information management functions, with only capacity changing by tier. The same page advertises daily backups, verified restores, a 99.9% uptime SLA, Australian support and a Sydney datacenter claim.

Those are meaningful customer promises, but each one raises a physical question. A vCPU plan depends on a host. NVMe depends on a disk subsystem. A daily backup depends on a destination, retention policy and restore test. A 99.9% SLA depends on exclusions, measurement and remedy. A Sydney datacenter claim depends on the actual supplier facility and where backup copies sit. The small price points make these questions more important, not less, because there is less financial room for spare idle capacity unless it is deliberately designed into the service.

The ABN and business names support continuity

The official business register gives Spiderweb a longer history than the current service pages alone. ABN Lookup reports that the active entity is CONSTABLE, MARK ANTHONY and that the ABN has been active since 2004. It lists RentaNet from 10 March 2014, Digital Mail Service from 9 June 2017, Spiderweb Cloud from 5 July 2018 and MOTD from 22 March 2022 as business names. It also lists AUwide Communications as a historical trading name from 1 September 2004.

This matters because the directory entity name is awkward: "Mark Anthony Constable for Spiderweb Cloud and" appears to come directly from a number-resource description, not from polished brand copy. The official business record explains why the same person, Spiderweb Cloud and RentaNet appear together across network and service material. It is a sole-trader operating structure with multiple registered business names, not a conventional corporate group with separate subsidiaries disclosed in the public record reviewed here.

The sole-trader model has two consequences for infrastructure risk. First, customer accountability may be clear in a simple way: the service brands connect back to one active ABN. Second, operational resilience may depend heavily on the availability, supplier accounts, technical knowledge and support relationships controlled by one principal or a very small team. That does not mean the service is weak. It means customers should test continuity of access as carefully as they test server specifications.

Public pages reinforce that support-centered model. Spiderweb publishes a phone number and says hours are 10am to 6pm AEST, seven days. RentaNET's pages publish the same phone number, contact address and support hours. The Spiderweb support-ticket form exposes Sales, Support and Billing departments, with high, medium and low priority options. That is a live support surface, not simply a brochure.

What it does not show is a restoration clock. A ticket form does not say who is awake at 03:00, who can reach a data-centre console, who can authorize a BinaryLane or Mammoth routing change, who holds DNS registrar access, or what happens if the billing system is unavailable. Small-provider continuity depends on those details. A buyer should ask for named escalation paths, account recovery controls and a tested process for substituting another technician or supplier contact if the usual operator is unavailable.

This is not a demand for a large-enterprise structure. It is a demand for a small-provider continuity map that matches the size of the promise. The public business continuity evidence is sufficient to treat the host as active; it is not sufficient to treat every support and supplier handoff as recoverable.

AS153475 is registered, but it is not carrying public routes

The network record is where the article's downgrade begins. APNIC's RDAP record for AS153475 lists the autonomous system as SPIDERWEBCLOUD-AS-AP, country AU, registered on 4 December 2024, with the description "Mark Anthony Constable for Spiderweb Cloud and" and "RentaNet offering Email and Web hosting services." It links the ASN to Spiderweb Cloud as registrant, an abuse contact validated in February 2026, and a Spiderweb Cloud administrator contact.

Registration is not the same as operation. RIPEstat's AS overview for AS153475 marked the ASN as not announced for 12 July 2026. Its routing-status view showed zero IPv4 prefixes, zero IPv6 prefixes, zero observed neighbours and no first-seen or last-seen route. Its announced-prefixes view returned no prefixes for the two-week window ending 12 July 2026.

That does not prove that the number will never be used. A newly registered ASN can sit idle while contracts, route objects, filters, cross-connects or address plans are prepared. A small host may register an ASN as future optionality, a migration step, or a way to hold portable addressing under its own policy later. But as of this review, the public route collectors do not show AS153475 as the origin for customer traffic.

The distinction is practical. If a customer believes Spiderweb operates its own routed edge, it may expect Spiderweb to move routes between providers during a transit failure. If the current services instead sit behind a supplier's ASN or provider-assigned space, route failover depends on supplier design and contract terms. The customer's risk is not merely "does the service have an ASN?" It is "which ASN is actually in the path, who can change it, and what happens when that party is unavailable?"

The absence of observed neighbours is also important. If AS153475 had two or more live upstreams, a customer could begin asking whether they are physically diverse, whether they have enough capacity after failover and whether route-origin authorization is current. Here the preliminary question is more basic: when will the ASN be brought into production, what prefixes will it originate, and what problem will it solve compared with the current supplier-origin routing?

Until that is answered, AS153475 should be treated as a registered control option, not as evidence of an operating edge.

The older Spiderweb address space is live, but supplier-originated

APNIC's organisation record for Spiderweb Cloud is the bridge between the dormant ASN and live routing. It lists two active IPv4 networks under the Spiderweb Cloud organisation: 203.25.132.0/24 and 203.25.238.0/24. Both are assigned portable IPv4 blocks with registration dates in September 2008 and last-changed dates in July 2023. Both are linked to the same Spiderweb Cloud contacts.

RIPEstat observed both prefixes as active on 12 July 2026, but the origin was not AS153475. The prefix overview for 203.25.132.0/24 and the prefix overview for 203.25.238.0/24 both identified Mammoth Media's AS133159 as the origin. The routing-status view for 203.25.132.0/24 and the routing-status view for 203.25.238.0/24 showed both routes visible to all 326 sampled full-feed IPv4 peers, with last-seen observations on 12 July 2026.

That is real network evidence. It says Spiderweb's portable address assets are not merely lying unused in a registry. At least two /24s are globally visible. It also says the operational edge is currently a provider-origin arrangement. Mammoth Media, not Spiderweb's own AS153475, is the origin seen by public collectors.

Provider-origin routing can be a sensible design. It can reduce operational complexity for a small host. The supplier already has upstreams, peering, monitoring, route filters, routers and data-centre access. A small customer can focus on managed service, mail, support and customer applications. But provider-origin routing changes the portability and restoration model.

If a Spiderweb server or service needs to move away from Mammoth Media or BinaryLane infrastructure, the buyer must know whether the portable /24 can be re-originated elsewhere, how long filters and route objects would take, whether there are valid route authorisations, and who is authorised to request the change.

The current route-origin validation result makes that question sharper. RIPEstat's validation checks for 203.25.132.0/24 and 203.25.238.0/24 returned unknown status with no validating ROA. Unknown is not the same as invalid. It means the public route-origin security evidence reviewed here did not show a current validating authorisation for the observed origin. For a provider-origin arrangement, route security and emergency portability should be documented rather than assumed.

The conclusion is narrow but important: Spiderweb has live routed address assets, but the public route table points to a supplier-operated edge.

Mammoth Media and BinaryLane become part of the risk model

Mammoth Media is not an obscure label in this chain. APNIC's RDAP record for AS133159 names MAMMOTHMEDIA-AS-AP, Mammoth Media Pty Ltd, Brisbane, Queensland. RIPEstat's AS overview marked AS133159 as announced on 12 July 2026. The ASN-neighbours view showed multiple observed adjacent networks, including large transit and network providers. PeeringDB's network record for AS133159 lists Mammoth Media, also known as BinaryLane, with Australian scope, IPv6 support, an open peering policy, 13 IX connections and six listed facilities.

BinaryLane's own website describes the commercial infrastructure layer more directly. The BinaryLane home page says it offers NVMe cloud servers, automated backups, load balancing, an external firewall, hourly billing and a management panel or API. The VPS hosting page says BinaryLane hosts servers in four Australian data centres: NextDC S1 in Sydney, NextDC M2 in Melbourne, NextDC P1 in Perth and NextDC B2 in Brisbane. It also advertises 99.9% SLA language for VPS hosting, IPv4 and IPv6 connectivity, redundant storage, automated daily backups as an option and load balancing as an option.

RentaNET's own services page names a BinaryLane partnership for enterprise Proxmox cluster management, with Australian data centres, hourly billing, NVMe SSD storage and direct peering. That is useful specificity: if a RentaNET customer buys a managed service built on BinaryLane or Mammoth infrastructure, the underlying data-centre and network claims may be inherited from that supplier rather than delivered from Spiderweb-owned racks.

Inherited resilience has limits. BinaryLane may have good data-centre reach, live migration and backup tools. That does not prove a particular Spiderweb or RentaNET service is deployed across multiple sites, backed up outside its primary failure domain, protected by a load balancer, or able to move between Mammoth-origin prefixes and AS153475. Supplier capability is not the same as customer-instance configuration.

This is where hosting economics becomes visible. A small annual plan can be viable because it rides a shared supplier platform, standardised server images, remote management and tightly scoped support. It may be excellent value for a small business website or mailbox. It should not be mistaken for dedicated high-availability architecture unless the contract and a test show that architecture exists.

The right procurement question is not "is Mammoth a credible supplier?" The public record suggests it is a visible Australian hosting network. The question is "which Mammoth or BinaryLane service is actually used for this customer, in which site, with which options enabled, under whose account, and with what tested recovery path?"

Location is Australian, but locality is not a single address

The record supports Australia as the service area. The ABN record is Australian, Spiderweb and RentaNET publish Australian contact details, APNIC marks the resources as AU, RIPEstat geolocation places the two Spiderweb /24s in Australia, and BinaryLane says its data centres are in Australian facilities. That is enough to reject a vague global-only profile.

It is not enough to locate the customer's data. The RentaNET pricing page says "Australian datacenter (Sydney)" in its infrastructure section. BinaryLane, meanwhile, says its server fleet spans Sydney, Melbourne, Perth and Brisbane. Spiderweb's privacy policy states that data may be held on servers in Australia and any other territories as Spiderweb sees fit from time to time, and that data may be transferred to listed parties in or outside Australia.

Those statements can be compatible. A specific RentaNET plan may be in Sydney. Some Spiderweb mail or web services may use other Australian infrastructure. External services such as DNS, CDN, payment, analytics, ticketing or email security may process data outside Australia. Backups may be local, remote or both. The public pages do not provide a per-service map.

For data sovereignty and locality, the customer needs a table, not a slogan. It should identify the production copy, backup copy, mail spool, web content, database, logs, DNS provider, registrar account, billing system, support ticket data and monitoring data. Each row should name the region, supplier, account owner, access path, retention period and exit method. If a plan is advertised as Sydney, the table should say whether backups also stay in Sydney or whether they move to another region for resilience.

Locality also interacts with recovery. A backup in the same site may be fast to restore after a user error, but weak against a site outage. A backup in another state may be better for disaster recovery, but may introduce jurisdictional and access-control questions. A CDN can improve performance but can hide origin dependencies until cache expiry or dynamic requests expose them. The buyer needs to understand those tradeoffs before an incident, not during one.

The public evidence therefore supports "Australian-hosted service with supplier dependencies." It does not support "all data remains in one named facility controlled end to end by Spiderweb."

Mail is the sharpest operational dependency

For many Spiderweb customers, the most sensitive failure path may be email rather than web hosting. Spiderweb's homepage publishes mail settings for IMAP and SMTP, encourages IMAP over POP, and says the server-side spam filter depends on users moving messages into the Junk folder rather than deleting them. The webmail login is a live customer access surface. The client portal includes account, service management, support ticket and payment links.

Mail hosting is operationally unforgiving. A website can often be cached or restored from a snapshot. Email requires continuous receipt, queue management, spam filtering, authentication records, TLS, mailbox storage and user-device synchronisation. If the IMAP server is unavailable, customers may lose access to current mail. If the SMTP path is blocked or misconfigured, outbound mail may be rejected or classified as suspicious. If DNS records are wrong, deliverability can degrade even when the mailbox server is healthy.

Spiderweb's public updates show that the operator understands some of these dependencies. The January 2026 Spiderweb update said a new server was deployed on Christmas Day to improve security and performance for hosting customers. It described the retirement of old unencrypted mail ports, published SSL/TLS mail settings, and named Postscreen, CrowdSec, Rspamd and Spamprobe as parts of the mail and security stack. The article should be read for the technical claims, not as proof of a full resilience architecture.

The operational question is what happens when that mail system fails. Is there a secondary inbound MX that queues mail outside the primary server? Are mailbox backups stored separately from the host? Can users export all mail in standard IMAP format? How quickly can the host be restored if a provider storage system fails? Can DNS and SPF/DKIM/DMARC records be changed if the normal control panel is unavailable? Who can remove a false block if a customer is locked out by security controls?

The answer may be perfectly adequate for many small businesses. A simple, well-run mail server with daily backups and responsive support can be more valuable than an expensive platform the customer cannot administer. But mail is where small-provider support promises become most visible. A customer who loses mail access during a campaign, invoice cycle or legal deadline does not experience an abstract hosting outage. It feels like a business interruption.

That is why the advertised mail features should be paired with a restore test and an export plan.

Backups are advertised, but restoration is the evidence that matters

Spiderweb's pay-as-you-grow pricing page states that servers are backed up every 24 hours and that all WordPress websites have their own backup system retaining three weekly backups. RentaNET's pricing page says daily backups and verified restores are included. BinaryLane's home and VPS pages describe automated or on-demand backups and the ability to restore full-disk images or attach a backup and retrieve individual files.

Those are all positive statements. They also describe different layers. A WordPress plugin backup, a server snapshot, a provider disk image and an off-site copy are not interchangeable. They capture different data at different times, restore at different speeds, and fail under different conditions. If all backups sit inside the same provider account and that account is locked, suspended or compromised, the backup may be technically intact but operationally unavailable.

The public record reviewed here does not show retention length for RentaNET managed server backups, storage location, encryption, restore time, test frequency or customer export rights. It does not say whether mailboxes, databases, DNS zones, TLS keys, billing records and support tickets are all included. It does not say whether a backup can be restored to another provider if Mammoth or BinaryLane infrastructure is unavailable.

This is not an unusual gap. Most small-host public sites do not publish detailed recovery reports. But the gap is still the customer's risk. A backup claim becomes resilience evidence only when the provider can show a recent restore, the source copy, the target environment, the time required, the data loss window and the steps the customer must take.

For Spiderweb and RentaNET, a good recovery proof would include three cases. First, restore a WordPress site from the weekly site-level backup. Second, restore a mailbox from the mail-server backup without losing folder structure. Third, rebuild a managed server in a different BinaryLane region or another supplier using the latest backup, DNS records and documented configuration. Each case should include the time to restore service and the time to verify data integrity.

Until then, daily backups should be treated as necessary but incomplete evidence.

Installed, advertised and recoverable capacity are separate

The public service pages expose three different capacity ideas. Installed capacity is what exists on the host or supplier platform. Advertised capacity is what is sold as a plan or option. Recoverable capacity is what remains usable after a failure or migration.

Spiderweb's PAYG hosting model advertises very small units: storage slots, WordPress sites and IMAP mailboxes. RentaNET's plans advertise vCPU, RAM and NVMe sizes. BinaryLane advertises VPS resources that can be changed from a control panel and billed hourly. Each statement is useful, but none tells a customer how much spare capacity exists during an outage.

For example, RentaNET says customers can grow one unit at a time without migration. That may be true inside the normal supplier platform. If the problem is a host failure, site failure, provider account problem or route failure, growth is not the issue. Replacement capacity and access to restore media become the issue. A plan with 4 vCPU and 8 GB RAM is recoverable only if another host with compatible capacity, storage, IP addresses and configuration can be made available within the customer's required time.

The same applies to "unmetered bandwidth for normal web and mail traffic" on the Spiderweb pricing page. It is a billing description, not a network capacity guarantee. A small website can be unmetered while still sharing a finite port, mail queue, upstream commit, CDN policy or anti-abuse threshold. The page also says abusive traffic trends may lead to suspended services. That is reasonable, but customers should understand who decides what is abusive and how quickly a false positive can be reversed.

Provider-origin routing also shapes capacity. If the two Spiderweb /24s are originated by AS133159, the ability to absorb failure depends on Mammoth's routing, data-centre connectivity and customer-specific configuration. The route table shows reachability, not the amount of paid bandwidth, number of hosts, storage pool health or available spare hardware behind a specific customer service.

The safe language is therefore: Spiderweb and RentaNET sell hosted and managed service capacity; public evidence does not establish how much of that capacity is independently installed, concurrently maintainable or recoverable outside the supplier environment.

The most credible failure paths are ordinary

No public evidence reviewed here identifies a specific outage, and none should be inferred. The credible risks follow from the dependency chain.

The first is supplier-platform failure. If a BinaryLane or Mammoth service component, data-centre power domain, storage system or network edge fails, Spiderweb's ability to restore service depends on the selected plan, backup location, support entitlement and account access. A provider with multiple facilities does not automatically make a customer's single-server deployment multi-site.

The second is route-control failure. Spiderweb's two portable /24s are active under AS133159. If the customer service depends on those addresses and needs to move, the operator must coordinate route-origin changes, filtering, route objects and possibly ROA creation. Because RIPEstat returned unknown route-origin validation for the observed AS133159 origin on both prefixes, the route-security state should be cleaned up or clearly documented before an emergency move.

The third is mail-system failure. The public mail settings, webmail login and January 2026 update show a mail service with spam filtering, encrypted ports and security controls. That is operationally meaningful. It also creates a dependency on mailbox storage, DNS records, queue handling, user passwords, blocklist handling and support response.

The fourth is backup and restore failure. A daily backup that cannot be restored quickly, restored into a new environment, or verified by the customer does not meet the recovery need. A WordPress backup does not necessarily protect mail. A server snapshot does not necessarily protect external DNS, billing, support records or registrar control.

The fifth is billing and account failure. The client cart exposes hosting and hourly support products, while the portal manages services, tickets and payments. If billing access is locked, a credit card fails, or the provider account is suspended, technical service can become dependent on administrative recovery. This risk is easy to overlook because it feels non-technical until it blocks a restore.

The sixth is support saturation. A small host can be very responsive in normal conditions and still become capacity-constrained when a server migration, mail issue, customer lockout and supplier ticket all happen together. Support capacity is part of infrastructure capacity. Customers should know the escalation route when ordinary channels are unavailable.

The seventh is migration failure. If a customer wants to leave, it needs website files, databases, mailboxes, DNS zones, domain access, certificates, configuration notes and backup copies in a usable format. A service is not truly portable if only the current operator can interpret or access its state.

None of these paths requires a dramatic incident. They are the normal ways small hosted services become brittle.

What would raise confidence

Spiderweb and RentaNET could improve public confidence without revealing sensitive details. The first improvement would be a service placement note. It should say which products run on Spiderweb portable IP space, which run on provider-assigned space, which use Cloudflare, which use BinaryLane or Mammoth infrastructure, and which are hosted elsewhere. It should also state whether RentaNET's Sydney datacenter claim applies to all plans or only selected managed containers.

The second improvement would be a route plan for AS153475. If the ASN is intended for production, the provider should say what prefixes it will originate, which upstreams will be used, whether there will be more than one site or carrier, and what customer benefit the change provides. If AS153475 is not yet in service, the site should avoid implying that it is the active edge.

The third improvement would be route-security hygiene. The two Spiderweb /24s should have documented route-origin authorization for the intended origin, whether that remains AS133159 or changes to AS153475. Route objects and supplier letters of authority should be current. Customers do not need private router configs; they need assurance that emergency route changes will not be blocked by missing paperwork or filtering.

The fourth improvement would be restore evidence. A short public statement could identify backup frequency, retention, storage region, restore-test frequency and expected restore times by product. A stronger customer-specific report would show a recent test for a website, mailbox and managed server, including whether the restore target was in the same provider or a separate environment.

The fifth improvement would be a support and authority matrix. It should distinguish customer support, server administration, supplier escalation, route changes, DNS changes, domain recovery, payment issues and data export. It should say who can approve each action and which channel remains available if the main portal is down.

The sixth improvement would be a data-location and portability statement. Spiderweb's privacy policy allows data to be held in Australia or other territories. Customers should receive a more precise statement for their service: production region, backup region, subprocessors, export format, retention after cancellation and deletion procedure.

These are proportional requests for a small provider. They do not require a hyperscale certification program. They ask for evidence that the purchased service can survive the most likely dependency failures.

What customers should not infer

Several public facts are useful but easy to overstate. An active ABN proves the business identity, not the engineering design. A registered ASN proves number-resource intent, not public routing. A routed /24 proves reachability, not rack ownership. A supplier's multi-data-centre footprint proves available supplier options, not that a particular Spiderweb service is deployed across them. A daily backup claim proves a stated process, not a successful restore.

The reverse is also true. AS153475 being unannounced does not mean customers have no service. The public sites, portal, webmail, pricing and APNIC-linked address blocks show a current operating surface. Small hosts often rely on upstream providers precisely because that is the sensible economic design. The issue is not existence. The issue is recoverable control.

Unofficial market and network signals should be used only as signals. PeeringDB helps identify Mammoth Media/BinaryLane's public interconnection profile, but it does not certify Spiderweb's customer deployment. RIPEstat route collectors show global visibility of the two /24s, but they do not show physical fibre paths, port capacity, storage layout, generator runtime or support staffing. A web page saying "Sydney" is useful, but it does not locate every backup or control service.

Customers should therefore ask the boring questions. Which facility or cloud region hosts my service? Which ASN and prefix carry it? Who owns the account? What happens if that account is suspended? Where are backups? When was the last restore? Can the service be rebuilt somewhere else? How do I export mail and website data? Who answers during a supplier incident?

Those questions may produce simple, reassuring answers. If they do, the service becomes more trustworthy. If they do not, the low price may be hiding a recovery dependency the customer should price separately.

The honest conclusion is a managed-service story

Mark Anthony Constable for Spiderweb Cloud and is best understood as a small Australian managed hosting and support operation with real public evidence: an active ABN, registered Spiderweb Cloud and RentaNet business names, current WordPress and email hosting pages, a client portal, a webmail login, RentaNET managed-server pricing, APNIC number resources and globally visible Spiderweb portable IPv4 space.

The network evidence also imposes a clear limit. The named Spiderweb ASN, AS153475, was not announced in the public RIPEstat views reviewed on 12 July 2026. The two active Spiderweb /24s were announced by Mammoth Media's AS133159. That does not make the service weak by default, but it shifts the resilience question from "does Spiderweb have an ASN?" to "how does Spiderweb manage supplier-origin routing, provider infrastructure, backups, support authority and customer portability?"

For a small business that needs a managed WordPress site, mailbox or Linux server, the public offer may be entirely appropriate. The support model may be the product. The value may lie in someone handling mail settings, updates, spam filtering, restore work and Linux administration at prices a small customer can afford.

For a customer with stronger continuity needs, the same evidence demands caution. Hosted capacity here still depends on racks or cloud hosts controlled by a supplier, transit originated by another ASN, daily backups whose restore scope is not public, support labor that may be concentrated, and migration paths that need to be tested before a failure. That is not a condemnation. It is the operating surface the buyer should measure.

The defensible grade is therefore Medium, with an independence downgrade. The business and services are visible. The address space is visible. The supplier network is visible. The missing proof is independent operational control and tested recovery.