Summary

  • Bird Hosting Inc. is the active registrant attached to AS19133 in ARIN's public record, with directly registered IPv4 and IPv6 resources and current global route visibility.
  • The customer-facing identity is different: PeeringDB associates AS19133 with Innovative Scaling Technologies, Inc., also known as InnoScale, and InnoScale's legal terms name that company as the contracting provider.
  • Public service pages offer concrete products, locations, an SLA and support channels, but their promises need to be read alongside exclusions, credit procedures, data-transfer language and inconsistent support contact details.
  • The record supports treating AS19133 as a real operating network. It does not, by itself, make the name Bird Hosting Inc. a complete assurance about the seller, service architecture, data location or incident response.

The strongest identity evidence starts with the network

Bird Hosting Inc. is not merely a brand name found on an old hosting list. The American Registry for Internet Numbers record for AS19133 identifies the autonomous system as BIRD-HOSTING, marks it active and names Bird Hosting Inc. as the registrant. The AS registration dates to January 2011. The linked organisation record, BIRDH, dates to May 2010 and was last changed in August 2025.

That record matters because an autonomous system is an operating identifier, not a marketing category. It is used to originate routes under a common routing policy. ARIN also publishes four direct resource records for the organisation: 71.19.224.0 through 71.19.239.255, 192.64.72.0 through 192.64.79.255, 204.11.16.0 through 204.11.19.255, and the IPv6 allocation beginning 2605:7900::. The ARIN resource list therefore supplies a stronger proof of infrastructure responsibility than a generic claim to offer hosting.

The BTW directory entry adds a useful but qualified view. It describes Bird Hosting as a US private company, lists hosting and managed-network services, and shows 17 related-network records plus a Seattle Internet Exchange membership. The service labels are marked as not yet assessed, while the exchange membership carries medium confidence. That is the right way to read a directory surface: it organises public clues and relationships, but it should not be mistaken for an uptime certificate or a statement about who has contractual liability.

The first conclusion is therefore fairly firm. Bird Hosting has a durable identity in internet number-resource records, and that identity is attached to infrastructure that remains visible. The harder question is what the name means to a customer buying a cloud server today.

One network presents two corporate names

ARIN's record itself points away from a standalone Bird Hosting storefront. Its organisation comments cite innoscale.net, and its technical, network-operations and abuse contacts use InnoScale email addresses. A named technical contact also uses the InnoScale domain. These links make a connection between Bird Hosting and InnoScale much more than guesswork.

The PeeringDB profile for AS19133 makes the connection explicit from another angle. It names the network Innovative Scaling Technologies, Inc., gives InnoScale as the alternate name, links to innoscale.net, and assigns the same ASN. The profile describes an open peering policy and classifies the network across access, content, enterprise and network-service-provider functions.

Yet the names are not interchangeable in the documents a buyer is asked to accept. The InnoScale terms of service state that the agreement is between Innovative Scaling Technologies, Inc. and the customer identified in the order form. The terms define services including cloud servers, clusters, private cloud and dedicated servers. Bird Hosting Inc. does not appear as the counterparty in that published agreement.

This is not evidence that either name is false. Companies often retain older resource-holding names, trade under a different brand, or place network assets and customer contracts in different entities. It is evidence that identity must be resolved at the order level. A prospective customer should ask whether Bird Hosting Inc. owns or operates the relevant resources for Innovative Scaling Technologies, whether one entity is a trade name or affiliate of the other, and which entity accepts service, privacy and financial obligations. The answer should appear in the order form or another binding document, not only in an explanation from sales.

Routes show an active network, not a quality score

On July 15, 2026, RIPEstat's routing-status view reported 25 visible IPv4 prefixes covering 13,824 addresses and 13 visible IPv6 prefixes, represented as 13 /48s. The network was visible to all 326 IPv4 and all 322 IPv6 full-feed peers counted by that view. RIPEstat also recorded a route originated by AS19133 on the day of publication.

That is meaningful evidence. It shows that AS19133 is not only registered but participating in global routing at the observation time. It also supports the idea that the network has enough address space and route diversity to serve more than a token web presence.

It does not show latency to a particular application, packet loss over a customer's chosen path, change-control quality, spare capacity, disaster recovery or the competence of an on-call engineer. Route visibility is binary evidence of reachability from monitoring peers, not a measure of end-user experience. Address holdings also say nothing about how densely a provider allocates servers, whether customer traffic is filtered correctly or whether an advertised location has independent power and network paths.

PeeringDB adds more operating clues, although its operator-supplied fields should be treated as declarations. The profile reports a global scope, 50-100 Gbps of traffic, 30 IPv4 prefixes and 10 IPv6 prefixes. Its related records list five facilities: Equinix AM1/AM2 in Amsterdam, DataBank IAD1 in Ashburn, Evocative DAL6, DataBank SFO1 in Santa Clara and Wowrack's Tukwila facility. Separate exchange records show AS19133 on two Seattle Internet Exchange networks, each at a stated 10 Gbps and each carrying IPv4 and IPv6 addresses.

Taken together, ARIN, RIPEstat and PeeringDB support an operating-network thesis. They do not independently validate the performance figures or customer-service claims made on InnoScale's own pages.

The service catalogue is concrete, but the claims are still claims

InnoScale's public site now contains enough detail to count as service proof rather than an empty brochure. Its navigation offers cloud servers, private cloud, managed clusters, Kubernetes, specialised application hosting, email, private AI hosting and infrastructure support. The cloud-server page publishes instance families with virtual CPU, memory, storage and hourly prices. It also claims a 99.999 per cent uptime SLA, storage performance of 250,000 IOPS and seven global datacentres.

Specificity is useful. A buyer can compare the published instance dimensions with an intended workload, ask how storage performance was measured, and check whether the quoted SLA applies to the selected architecture. The terms also say that InnoScale may assign and manage dedicated IP addresses and may change or remove them. That clause connects the resource-holding evidence to a plausible customer service, while also making clear that a customer does not obtain control of the underlying address rights.

But a price table and a performance headline are not independent verification. The public record reviewed here does not include benchmark methodology, a historical status record, audited availability figures or a customer-specific reference architecture. The site even compares its performance and cost with a large hyperscaler without publishing a reproducible comparison in the same place. Those statements are commercial propositions to test, not facts to enter into a risk model unchanged.

A useful procurement response is to make the offer measurable. Ask for the exact CPU generation, overcommit policy, storage replication design, IOPS test conditions, network-port limits, backup boundaries and restoration process. Ask whether the proposed service is a single virtual machine, a replicated cluster or a managed application. These details determine whether the headline availability figure has any practical meaning.

Location choice is not the same as data sovereignty

The cloud-server page names Seattle, Santa Clara, Chicago, Washington, Dallas, London and Amsterdam, with an Asia-Pacific location described as coming soon. That list is broader than the five facilities in the current PeeringDB record. The difference is not necessarily a contradiction. A provider can sell a location without operating a public peering port there, and a facility record can omit a service site. It does mean that neither list should be used as a substitute for a binding deployment location.

The legal text is more revealing. InnoScale's data processing agreement names Innovative Scaling Technologies as the processor, covers hosting, cloud infrastructure, storage, backups and technical support, and allows personal data to be transferred to the United States or other countries where InnoScale or its subprocessors maintain facilities. It says a subprocessor list is available on request and refers to safeguards for international transfers.

For a customer with residency obligations, that language makes a city selection only the start of the discussion. The primary server may sit in Amsterdam while telemetry, backups, support access or a subprocessor crosses another jurisdiction. The public DPA does not provide the requested subprocessor list, a fixed support-access geography or a service-specific data-flow map.

Operating assurance therefore requires a written location schedule. It should identify production data, replicas, backups, logs, management-plane data and support access separately. It should state whether each can leave the selected jurisdiction, name the subprocessors involved and explain what happens during failover. Without that schedule, a location label describes a product option, not a complete sovereignty boundary.

Support accountability runs on two different clocks

The InnoScale support page promises 24-hour availability, a response within 30 minutes for critical issues, multilingual assistance, monitoring and incident-response services. It presents email, chat, phone and ticket channels and lists [email protected] as the email route. The site's navigation directs technical support and billing to a customer portal.

ARIN's public network record tells a narrower story. Its network-operations comments state hours of 9am to 5pm Pacific time and direct after-hours contacts to leave a message or send email. The listed operational and abuse address is [email protected]. The published SLA gives yet another incident route, [email protected].

These details may refer to different functions. A registry NOC contact exists for routing, abuse and resource administration; it need not be the same team that handles paid managed-support incidents. A 24-hour support desk can also triage cases before an infrastructure specialist is engaged. Even so, the public presentation leaves a buyer with three email patterns and two apparent coverage models.

That ambiguity should be resolved before an outage. The order should name the authorised incident channel, severity definitions, acknowledgement target, technical-engagement target and restoration objective. It should say whether the 30-minute promise is an acknowledgement or the arrival of a qualified engineer. It should also identify who can make route changes, restore backups and communicate during a security incident outside normal Pacific working hours.

Local support labour matters here. A badge saying 24/7 says nothing about where staff are employed, whether coverage is staffed or on call, or whether the people receiving the ticket have privileged access to the affected systems. Buyers that depend on regional language, jurisdictional restrictions or rapid hands-on intervention should ask for the support-location and escalation model in writing.

The SLA is a remedy framework, not five nines in isolation

InnoScale's SLA is more useful than a bare uptime slogan because it explains part of the remedy. It says the company will use commercially reasonable efforts to maintain 99.999 per cent monthly availability. It offers credits of 5, 10 or 25 per cent at lower availability bands, caps the monthly credit at 25 per cent of the affected service charge and requires a written claim within ten business days. Eligibility is determined by InnoScale, and approved credits are applied to a later invoice.

The conditions narrow the headline. The exclusions include third-party telecommunications, customer software, events outside InnoScale's control, scheduled and emergency maintenance, customer conduct, provisioning constraints, specified hardware or software, and a single development-cloud server or single dedicated server. Scheduled outages are excluded from the measurement. The published credit bands also jump from an upper bound of 99.98 per cent to a lower bound of 99.99 per cent, leaving a small interval that merits clarification.

For a customer, the practical questions are straightforward. What monitoring source determines availability? Is the unit a host, virtual machine, cluster, region or service endpoint? Does a partial performance collapse count as unavailable? Which architecture qualifies, given the single-server exclusion? Who preserves the evidence needed to submit a claim within ten business days?

The SLA can still be valuable. It creates a documented route to a credit and establishes a monthly measurement concept. But even the maximum credit is not compensation for lost data, missed transactions or reputational harm. Resilience must be designed into the purchased service; it cannot be inferred from the number of nines on the sales page.

What a buyer should require before relying on the name

Bird Hosting's public record has enough substance to justify continued diligence. The network registration is long-lived. The address resources are identifiable. Current routing observations show broad visibility. A related public brand offers priced services, an account portal, legal terms, a DPA, an SLA and support channels. This is considerably more evidence than a company name with no operating surface behind it.

The remaining gaps are also concrete enough to close. A buyer should require five things: a signed explanation of the Bird Hosting, Innovative Scaling Technologies and InnoScale relationship; an order form naming the liable counterparty; a service diagram tying the purchased workload to AS19133, facilities and failover paths; a data-location and subprocessor schedule; and a support matrix that reconciles hours, channels, severity targets and escalation authority.

Those requests are not paperwork for its own sake. They connect four surfaces that the public internet keeps separate: the holder of number resources, the operator of the routed network, the seller of the service and the team accountable when service fails. When all four are aligned, the public record becomes useful corroboration. When they are not, a familiar hosting name can create confidence without assigning responsibility.

The fair verdict is therefore neither dismissal nor endorsement. Bird Hosting Inc. has a real and active network footprint behind its name. The evidence is strongest on registration and routing, reasonably developed on service definition, and weaker where customers need the most exact promises: corporate accountability, service-specific locality and after-hours operational response. Until those links are made binding, AS19133 is evidence of operation, not a warranty of outcome.