Summary
- Tekify Broadband has a much stronger public operating footprint than a thin-footprint warning would imply. Its homepage says Tekify Fiber and Wireless serves the southern and eastern portions of the San Francisco Bay Area with business and residential internet, and its residential page and business page describe fibre and carrier-grade microwave access, Ethernet handoff, static IP address features and selective coverage in Hayward, Fremont, Newark, Union City, Santa Clara and San Jose.
- The network identity is also real. ARIN's AS46886 RDAP record names
TEKIFY-BROADBAND - Tekify Broadband, and RIPEstat's AS overview marks the ASN announced at the 2026-07-10 query snapshot. RIPEstat's routing status shows 25 IPv4 prefixes, one IPv6 aggregate and eight observed neighbours; PeeringDB lists Tekify Broadband Internet Services as a Cable/DSL/ISP at SFMIX, FCIX and two Hurricane Electric Fremont facilities. - The operating boundary is still local and selective, not a national carrier story. Tekify's check-address page asks users to test a specific street address against its service-availability database, and the residential page says speeds and services vary by location. That matters because a 10Gbps regional claim can coexist with neighbourhood-specific construction, rooftop wireless reach, building access limits and last-mile repair constraints.
- The clearest failure path is not a missing ASN; it is the access chain between the Bay Area customer site and the Tekify edge. Tekify's Mission Critical SLA promises a four-hour local-loop restoration target for qualifying dedicated internet service after a customer opens a ticket, but it also excludes customer-caused delay, denied physical access, other ISP networks, force majeure, scheduled maintenance and cases where proper power is not available to customer-premises equipment. The Basic SLA is weaker: best-effort repair, limited to Monday through Friday, 9am to 5pm.
- The evidence grade is Medium. Tekify is a visible Bay Area ISP with live routing, address space, public support and regulatory postings. The public record does not verify per-address fibre route maps, tower inventory, pole rights, battery runtime, spares, crew staffing, outage history, busy-hour utilisation or how quickly a field technician can reach every served roof, building telecom room or customer-premises device.
A Bay Area operator, not only a registry string
The first correction is simple: Tekify Broadband is not just an autonomous-system label. Tekify's own homepage presents the company as Tekify Fiber and Wireless, an internet service provider for the southern and eastern portions of the San Francisco Bay Area. The same page says it serves Hayward, Fremont, Newark, Union City, Milpitas, Santa Clara and San Jose, and its page metadata adds San Leandro. It also advertises speeds up to 10Gbps through fibre optic and carrier-grade microwave wireless networks. Those are first-party statements, but they are specific enough to locate the service thesis: this is a local and regional access provider trying to sell fast connectivity where cable, telephone and slower business circuits are not enough.
The residential surface is similarly concrete. Tekify's residential internet page says its internet services are available in select neighbourhoods and many business parks within Hayward, Fremont, Newark, Union City, Santa Clara and San Jose, and then narrows the residential coverage section to homes throughout Hayward, Fremont, Newark and Union City. The page says Tekify uses both fibre and wireless. In some neighbourhoods, according to the page, fibre runs directly into some homes while also feeding wireless radio systems; in others, fibre feeds wireless radio systems that serve homes wirelessly. It says homes with wireless access receive a small wireless receiver and can reach up to 1,000Mbps, while limited areas can receive 10Gbps.
The business page extends the same logic to commercial sites. Tekify's business internet and VoIP page says the company serves business customers in Hayward, Fremont, Newark, Union City, Milpitas, San Jose and Santa Clara, with fibre and carrier-grade microwave wireless networks. It says new business customers generally qualify for 100Mbps to 1,000Mbps download and upload, and it says Tekify is prepared to deliver high-capacity services up to 10Gbps to commercial locations in days, not weeks, including events, temporary construction sites and office relocations. That is a meaningful public claim because temporary construction and relocation demand can stress the difference between a provider that owns or can rapidly extend access and one that only resells a slow third-party construction process.
The contact and support pages reinforce that this is not just a marketing one-pager. Tekify's contact page gives the customer-facing phone number (510) 266-5800, states normal office hours of Monday through Friday, 9:00am to 6:00pm Pacific Time excluding holidays, and says limited after-hours support is available for service outages. The technical support page asks customers to file a support request for technical problems, says an on-call technician is notified, and gives an expected reply within 30 minutes during business hours for urgent outages or six business hours for non-outage requests. Those facts do not prove the size of the field team, but they do show a public service process and a local support expectation.
California regulatory postings add a second operating layer. Tekify's regulatory postings page says Tekify, LLC provides internet access to business and residential customers within California, and it links residential network-management, acceptable-use, terms, privacy and fee documents. The same page has a Tekify Fiber, LLC section with a 2026 California Service Guide. That guide identifies Tekify Fiber, LLC as a facilities-based and resold competitive local exchange carrier in California, gives utility number U-7317-C, and says the California Public Utilities Commission authorized it to provide competitive local exchange service and interexchange service. A CPUC decision document also frames Tekify Fiber's application as a certificate request for full facilities-based and resold local exchange services in incumbent territories and statewide interexchange services.
Those telecom-authority facts should not be stretched into proof of retail broadband reach at every address. A certificate and service guide show a regulated communications-service authority and the legal surface for certain services; they do not publish a street-level broadband plant map. Still, they matter. A provider with a public internet access site, customer-support process, California regulatory postings, a CPUC-authority context and a live autonomous system is materially different from a shell record. The evidence supports treating TEKIFY-BROADBAND as a real regional ISP lens. The right downgrade is not "no operator found." It is "real operator, selective footprint, unproven physical diversity."
Service area is selective, and that selectivity is the first resilience clue
Tekify's service-area language is unusually candid in one important way: it repeatedly tells users that availability varies by location. The homepage lists Bay Area cities, but the check-address page asks for a complete street address and says Tekify will cross-reference the address against its service-availability database to tell the user whether fibre and/or wireless internet services can be subscribed to at that location. That page is the key to interpreting every speed claim. Tekify can be a local provider in several Bay Area cities while still serving only particular streets, buildings, rooftops, business parks or wireless sectors inside those cities.
That selectivity is normal for a fibre-plus-fixed-wireless access provider. Fibre construction follows ducts, poles, building access agreements, permits, cost justifications and anchor tenants. Fixed wireless follows line of sight, rooftop rights, antenna height, spectrum, interference conditions, power at radio sites and the ability to put a receiver at the customer premises. A provider can have a fibre route close to one building but not close enough to serve the next one without construction. It can have a wireless signal to one side of a neighbourhood but not through trees, hills, apartment walls or a blocked rooftop. The customer sees a binary sales answer - service available or not - but the operator is managing a geometry problem.
Tekify's residential page makes that geometry explicit. It says fibre may run directly into some homes and simultaneously feed wireless radio systems so nearby homes can receive fibre-like service. In other neighbourhoods, the page says fibre runs only to wireless radio systems and all homes in the neighbourhood are served wirelessly. That mixed design can be efficient. It lets a small provider use fibre where construction makes sense and use rooftop or tower-fed wireless where the cost of every drop would be too high. It can also concentrate risk. A fibre feeder into a radio site becomes a dependency for many homes beyond the fibre line. A powered radio site becomes a dependency even when the underlying fibre backhaul is intact.
The business page adds another important clue: construction and upgrades are location-dependent. It says pricing depends on required speeds and whether Tekify needs to upgrade existing facilities or construct new facilities to reach a location. That is the plain language of regional-ISP economics. The monthly price of a line is not only transit and router cost; it is the amortised cost of getting physical infrastructure to a specific building, keeping it powered, maintaining the customer equipment and dispatching a person who can reach the point of failure. For a temporary construction site or an office move, the provider's advantage may be the ability to improvise an access path faster than a traditional fibre build. The same improvisation can become a fragility if the customer assumes the path has the same protection as a carrier-diverse fibre ring.
This is why the regional-ISP category fits, but only with discipline. Tekify is not selling a nationwide consumer broadband footprint. It is presenting an access network in a set of Bay Area localities, with residential, small-business, dedicated internet and VoIP offerings. The available evidence supports Regional ISP economics, Local support labour and Peering and transit as controlled topics. It does not support a stronger claim such as guaranteed metro-wide coverage, address-universal fibre, fully redundant last-mile construction or independent route diversity at every customer site.
The practical customer consequence is direct. A household in a served Union City neighbourhood and a business in a served Hayward business park may both receive a bill with the same brand on it. The household may be on a wireless receiver fed by a fibre-backed radio site. The business may be on a dedicated Ethernet handoff with an SLA. The outage path, repair queue, after-hours response and power dependency can be very different. Tekify's public pages give enough information to know that those differences exist; they do not publish enough information to grade each service design.
Fibre, microwave and Ethernet make the asset real but not self-explanatory
The access asset behind Tekify's public offer is a hybrid. The homepage describes a fibre optic and carrier-grade microwave wireless network. The residential page describes fibre into some homes, fibre-fed wireless systems in other places and a small wireless receiver at the home where wireless is used. The business page says Tekify can deliver over fibre or wireless and says every plan includes static IP address features. The homepage and business page both say service is delivered over a standard Ethernet cable to the customer's router, with no modem rental. That matters because Ethernet handoff is the point where a customer's local network begins and the provider's access responsibility usually ends.
The installed asset stack is therefore at least four layers. First is the Bay Area backbone and internet edge, where AS46886 announces routes and exchanges traffic. Second is the metro or local distribution path: fibre routes, building entrances, rooftop backhaul, microwave links and aggregation nodes. Third is the last segment into the premises: direct fibre, a wireless receiver, an Ethernet handoff, customer-premises equipment and managed router if supplied. Fourth is the customer's own local network: Wi-Fi, devices, switches, phones, cameras and servers. Public marketing often collapses those layers into "internet speed." Failure analysis cannot.
Tekify's network-management disclosure is useful because it separates advertised service from actual performance. It says advertised speed is the maximum expected to be achievable for a service offering, and lists factors that may affect speed, including the subscriber device, equipment between the subscriber device and Tekify's network, websites or other internet services, CDN connectivity and capacity, Wi-Fi use and network congestion. It also says Tekify does not charge usage-based fees for internet access and does not employ volume-based data caps. That is not a current capacity report, but it is a public admission that maximum access speed is not the same as every-session performance.
The same disclosure describes congestion management. It says that if aggregate demand exceeds available network capacity and creates acute congestion, Tekify will fairly allocate bandwidth among subscribers without regard to activity, protocol or application, except to prioritise real-time communication such as VoIP so service availability and quality are not affected. That is a standard kind of broadband management language. It does not prove congestion is frequent; it identifies the rule Tekify says it will use if congestion occurs. The important fact for a resilience reader is that fair sharing is a customer-impact mechanism. A customer may not see a total outage, but can still see slow uploads, slow application response or degraded voice quality if access or upstream capacity is tight.
Public sources do not reveal the fibre route map, duct rights, pole attachment status, rooftop agreements, tower leases, microwave hop design, radio equipment, frequency plan, backup-power runtime or inventory of customer-premises equipment. They also do not say whether the "carrier-grade microwave" links use diverse rooftops or converge on a small number of common relay points. Those unknowns are not defects in themselves; small providers rarely publish that level of infrastructure detail. But the unknowns set the limit on the operating claim. The asset is real. The topology is not fully public.
This matters most for high-speed claims. A 10Gbps service in a limited area may be a direct fibre product with enough backhaul and optical headroom. A 1,000Mbps wireless service may be feasible to a close site with clean line of sight. A 200Mbps or 450Mbps residential wireless tier may be robust in a neighbourhood where radio sectors are lightly loaded. None of those facts tells us how the system behaves when a feeder fibre is cut, a rooftop loses power, smoke or rain affects a link, a landlord denies roof access, or a scarce technician is already on another outage. The public record gives the service envelope; it does not publish the stress test.
AS46886 is live, visible and more diverse than a thin-footprint ASN
The routing evidence is the strongest part of the Tekify case. ARIN's AS46886 RDAP record names TEKIFY-BROADBAND and the registrant Tekify Broadband at a Hayward, California address. RIPEstat's AS overview says the resource is announced and identifies the holder as TEKIFY-BROADBAND - Tekify Broadband. That immediately separates Tekify from providers whose website exists but whose own ASN is dormant.
RIPEstat's routing-status endpoint gives the measured shape: 25 IPv4 prefixes, 5,120 IPv4 addresses, one IPv6 aggregate and 4,096 /48 IPv6 units visible at the 2026-07-10 snapshot, with broad RIS peer visibility and eight observed neighbours. RIPEstat's announced-prefixes endpoint shows families such as 104.36.252.0/22, 104.193.128.0/22, 158.51.192.0/22, 165.140.16.0/22, 170.178.140.0/22 and the IPv6 aggregate 2602:ffa4::/36, often along with component /24 announcements. The component routes matter because they may support traffic engineering, deaggregation or address-family management. They do not by themselves tell us which customers are on which prefix.
The ARIN allocation trail confirms several of those address families. ARIN's RDAP record for 158.51.192.0/22 names TEKIFY-BROADBAND and Tekify Broadband as registrant. ARIN's 165.140.16.0/22 and 170.178.140.0/22 records likewise identify direct allocations to Tekify Broadband. The IPv6 allocation 2602:ffa4::/36 is also a direct allocation to Tekify Broadband, and RIPEstat's prefix overview shows it announced by AS46886. A sample RIPEstat RPKI validation for 104.36.254.0/24 reports a valid origin under a route-origin authorisation for AS46886. The route-security evidence is not a resilience guarantee, but it is good hygiene.
PeeringDB adds an interconnection view. The PeeringDB record for AS46886 lists Tekify Broadband Internet Services as a Cable/DSL/ISP with reported traffic of 1-5Gbps, mostly inbound ratio, open policy, two internet exchange counts and two facility counts. The nested data lists SFMIX and FCIX entries at 1Gbps each, and facility entries at Hurricane Electric Fremont 1 and Hurricane Electric Fremont 2. PeeringDB is voluntary and self-reported, so it should not be treated as audited capacity. It is still operationally meaningful: a network at local exchanges and Fremont facilities has a different internet-edge posture from a small access provider with a single hidden transit feed.
The observed-neighbour list is useful but should be interpreted carefully. RIPEstat's ASN-neighbours endpoint sees neighbours including AS6939 and AS33228, plus several smaller adjacent ASNs. RIPEstat's routing-consistency endpoint sees the main announced prefixes as both in BGP and in whois or IRR sources, and lists imports and exports observed in BGP. That is evidence of a live public routing edge. It is not evidence that each customer has two physically diverse uplinks, two CPE routers, two roof paths or two independent local fibres.
The failure path is therefore not "the internet cannot find Tekify." It can. The public BGP table sees Tekify. The better question is where AS46886 reaches the customer. If a customer is on direct fibre into a business park, the vulnerable path may be a duct, building entry or aggregation switch. If a customer is on wireless, the vulnerable path may be the rooftop receiver, relay radio, radio-site power and fibre feeder. If a customer is buying dedicated internet, the vulnerable path also includes the dedicated loop, customer CPE, support ticket process and any SLA tier. BGP visibility tells us Tekify reaches the global routing system. It does not tell us how many local physical paths exist between each served address and that edge.
Installed capacity, advertised capacity and usable capacity are three different questions
Tekify's public offer uses large numbers: 10Gbps in limited areas, 1,000Mbps residential download and upload for many new residential customers, and business plans from 100Mbps to 1,000Mbps plus higher-capacity service where facilities support it. It also says residential pricing starts at $49 per month in many areas and that many plans include professional installation. Those numbers are useful because they show the market Tekify is addressing: homes and businesses that want faster upstream, static IP features, quick installation and alternatives to cable or telephone-line access.
They do not provide a utilisation report. The difference between installed capacity and usable capacity is especially important in a hybrid fibre/wireless network. Installed capacity is the interface rate and route inventory: the fibre, radio link, switch port, router interface, upstream commit and advertised prefixes. Usable capacity is what a customer can actually use at the busy hour after sharing, radio scheduling, Wi-Fi limitations, CPE performance, upstream transit, CDN reach and congestion management. Tekify's network-management disclosure recognises that difference by saying advertised speed is the maximum expected to be achievable and by listing device, Wi-Fi, intermediate equipment, websites, CDNs and congestion as factors.
RIPEstat's routing data confirms that Tekify has a real public IP edge with thousands of visible IPv4 addresses and an IPv6 aggregate. That number-resource inventory supports static IP service and customer segmentation, but address count is not throughput. A /22 is 1,024 IPv4 addresses. Four visible /22 families and related deaggregates can support many customers and infrastructure uses, but they do not disclose paid subscriber count, traffic volume, peak utilisation or oversubscription. PeeringDB's 1-5Gbps self-reported traffic range is a helpful signal about scale, not an audit and not a per-link headroom statement.
Tekify's business page says pricing depends on whether existing facilities need upgrades or new construction. That is the operating-economics paragraph in the open. A provider can have a 10Gbps-capable backbone and still face a customer-specific construction cost if a building is off-net, if rooftop wireless is blocked, if fibre cannot be extended without permits, or if a temporary site needs a special design. Conversely, a provider can deliver strong service to an on-net business park because fibre, radio alignment and building entry already exist. This is why address qualification is not merely a sales form; it is a capacity and repair signal.
The residential tiers show the same split. A home that is already connected may be remotely activated, according to the residential page. That suggests there are prebuilt drops or installed premises equipment in some locations. A home on a new wireless receiver needs an installer, a mounting location, line of sight, cabling into the house, a router handoff and possibly landlord or homeowner approval. A home on direct fibre needs a physical path and optical termination. Each service path can have the same brand and similar billing experience but a different field burden when things break.
The correct conclusion is neither to dismiss Tekify's capacity nor to accept every advertised number as a delivered resilience fact. The public record supports live routing, address space, exchange presence, high-speed retail claims and a support process. It does not provide measured busy-hour throughput, packet-loss history by neighbourhood, customer counts, congestion events, repair-time distribution, backhaul utilisation or the ratio of fibre-served to wireless-served accounts. For an infrastructure-company profile, the difference matters because a customer buys a service experience, not a prefix list.
SLA language shows how resilience is sold and where it stops
Tekify's dedicated internet SLA documents are the most revealing failure-path sources. The Mission Critical SLA says Tekify's IP backbone network is guaranteed to make service available 99.99% of the time, with backbone latency of no more than 65ms, packet loss not above one percent and network jitter not above 10ms during a calendar month. It also says that in a local-loop outage, Tekify guarantees restoration within four hours from the time the customer reports the outage, with credits if service is not restored within that period. It differentiates dual-circuit dual-router sites from single or dual circuit single-router sites, and its credit tables are more favourable for dual circuit dual router designs.
That is stronger than a generic residential support page. It means Tekify has a formal dedicated-service product vocabulary: backbone, local loop, customer site, CPE, hard outage, soft outage, circuit, router and mean time to repair. It also means resilience is productised. A mission-critical design with two Tekify-provided routers, diverse circuits and a hot-standby protocol is not the same as a basic design with one router and one or more backbone circuits. The SLA itself encodes the engineering lesson: redundancy must be bought, installed and measured at the site, not merely assumed because a provider has multiple exchange peers.
The Basic SLA is a useful counterweight. It has the same kind of backbone availability, latency, packet-loss and jitter language, but it says the customer is not entitled to credits for several failures, and its repair clause says Tekify will make a best-effort attempt to repair the outage in a timely manner, with repairs limited to Monday through Friday, 9am to 5pm. That is a clear product boundary. A small business buying basic service and a site buying mission-critical dedicated internet may both see Tekify as the provider, but the repair expectation and credit exposure are different.
Both SLA documents include exclusions that expose the physical world behind the contract. SLA measurements exclude customer-owned equipment, the customer's local area network, scheduled maintenance, customer-caused interruptions, certain third-party-controlled interruptions, interconnections to or within other ISP networks and force majeure events. Credits are not due for customer delay, including delays that prevent Tekify from physically accessing CPE for repairs. Credits are also not due if proper power is not available to the CPE. These exclusions are not unusual; they are the ordinary boundary between a provider network and customer premises. But in a local access network, that boundary can be where the outage actually lives.
Consider a wireless receiver on a customer's roof. If the roof has power, line of sight and a clean cable path, a Tekify technician can troubleshoot the CPE and link. If the customer cannot provide access, if the roof is locked, if the landlord controls the telecom room, if the device has no power, or if the customer LAN is misconfigured, the provider's restoration clock is constrained. Consider a direct fibre handoff in a business park. If the fibre drop is damaged inside a locked building space, Tekify may need building access. If the failure is in a third-party network beyond Tekify's handoff, the SLA may exclude it. The contract language is a map of operational friction.
The public support pages add a softer layer. Tekify's contact page says limited after-hours support is available for service outages. The support request page says an on-call technician is notified and gives reply expectations. Those are useful customer-facing facts. They do not show how many technicians are on call, which cities have field staff, whether splicers are in stock, whether spare radios and routers are available, whether tower climbs are required, whether contractors are used, or whether repairs can be performed during storms, fires, smoke events, rooftop lockouts or commercial-building closures.
That is why the resilience downgrade belongs here, not in the identity section. Tekify's public evidence is strong enough to say it operates. It is not strong enough to certify field-repair depth. The customer-impact question is not whether Tekify has an SLA PDF; it is whether the actual customer path is mission-critical, basic, residential wireless, direct fibre, construction-dependent, or a custom design whose weak point sits in a place the public record does not identify.
Power, premises access and local labour are not side issues
Power is the quiet dependency in a fixed-wireless and fibre access network. Fibre can remain physically intact while active electronics lose power. Microwave radios need power at radio sites and receivers. Customer premises equipment needs power at the site. Aggregation switches, routers and optical gear need power at nodes. Wi-Fi routers need power inside homes and offices. A failure in any one of those places can look to the customer like an internet outage, even if AS46886 remains perfectly visible on the global table.
Tekify's SLA exclusions point directly at this issue by saying credits are not due if proper power is not available to CPE. That is a reasonable contract line, but it also tells the reader where the public evidence stops. The public record does not show battery runtime for customer-side receivers, business CPE, rooftop radio sites, aggregation equipment or Fremont facility equipment. It does not show generator coverage, UPS maintenance, battery replacement cycles, monitoring systems or whether customers with mission-critical needs are advised to protect the Tekify handoff with their own backup power. In practice, a small office that keeps laptops alive but not its CPE can still lose internet during a local power event.
Physical access is just as important. The Mission Critical SLA defines customer time to include delay from incorrect information, denied access to CPE or network components at the customer location, refusal to release a circuit for testing, or customer unavailability where needed to close a ticket. The Basic SLA has similar access-related exclusions. This is the local-support-labour problem in contract form. A provider can have an on-call technician and spare equipment, but the repair still waits if the telecom room is locked, the roof is unavailable, the customer cannot be reached, or a building manager controls the access path.
Tekify's own service pages imply a hands-on field operation. Residential plans list professional installation in one to three days for popular tiers, and the page says accounts already connected to Tekify may be remotely activated. Business pages describe rapid installation and high-capacity service for relocations, temporary construction sites and events. The support page says an on-call technician will receive a support request. Those facts suggest Tekify's service is not only a back-office resale. There is a local installation and support operation. But the public pages do not quantify it. They do not state how many crews are available, whether after-hours repair is performed by employees or contractors, how splicing is staffed, which cities have local stock, or how storm or wildfire-smoke conditions affect access.
Labour depth is particularly important for a regional ISP because the economics are tight. Large incumbents can spread spares, trucks and dispatch centres over a huge base. A smaller access provider can be faster because it is local and knows the buildings, but it can also be constrained if multiple faults occur at once. A single cable cut, radio-site outage, equipment failure or customer-premises incident may be manageable. Several simultaneous failures after a power event or construction accident can expose whether the operator has enough people, spares and escalation paths.
The public evidence therefore supports a local-support topic but not a strong repair-grade. Tekify has a support form, phone number, office hours, after-hours outage language, SLA clauses and product-specific repair expectations. It does not publish historical restoration performance, field crew headcount, repair queue data, spare CPE inventory, fibre splicing capacity, tower or roof access agreements, or battery-backed site lists. A customer who needs the line for payment systems, remote work, surveillance, VoIP, construction-site coordination or event connectivity should ask those questions before relying on the headline speed.
Upstream and peering look credible, but local access can still be single-route
Tekify's internet edge is visible enough that the upstream question becomes more nuanced. RIPEstat sees AS46886 as announced, with multiple observed neighbours. PeeringDB lists Tekify at SFMIX and FCIX, and at Hurricane Electric Fremont 1 and Fremont 2. The presence of AS6939 in the observed-neighbour data is consistent with the Hurricane Electric ecosystem visible in PeeringDB, and FCIX/SFMIX exchange points fit the Bay Area geography. This is a stronger edge posture than a provider that merely buys a private handoff and never appears under its own ASN.
Still, exchange presence is not the same as customer-path diversity. An internet exchange port can improve routes to peers and content networks, but the customer site still needs to reach Tekify's edge. A facility listing means Tekify has a presence or declared presence in a data-centre location, but it does not reveal how many local aggregation paths feed that facility. A pair of exchange entries does not tell us whether a Hayward home, a Fremont business park, a San Jose temporary site or a Union City rooftop radio sector has a second physical route if the primary feeder fails.
That distinction is central to resilience. Public routing can survive while a neighbourhood is down. AS46886 can continue announcing prefixes from Fremont while one fibre-fed wireless site loses power. Peering to SFMIX or FCIX can remain healthy while a customer receiver is misaligned, a roof switch is offline, a cable is cut at a building entry, or a landlord blocks after-hours access. From the customer's perspective, the route to the internet is broken. From a route collector's perspective, Tekify's ASN is healthy. Both facts can be true at the same time.
The reverse can also happen. A customer access line can be intact while an upstream or peering issue affects reachability to particular networks. Tekify's RPKI sample is valid for a 104.36.254.0/24 origin, and RIPEstat's consistency data sees the main prefixes in both BGP and registry or IRR sources. That reduces the risk of accidental invalid origin filtering for those routes, but it does not eliminate upstream congestion, route leaks, exchange-port failure, bad traffic engineering, or an outage outside Tekify's own network. Tekify's network-management disclosure also says connectivity and capacity of CDNs and other internet services can affect performance. A user may blame the access provider for a bad application session even when the bottleneck is elsewhere.
For buyers, the right verification task is specific. Ask which AS originates the service prefix, whether the site uses Tekify-owned or third-party transport to reach AS46886, how many upstreams are active for that customer class, whether the customer receives IPv6, whether the route is protected by RPKI, whether exchange peering is used for the customer's traffic, and whether a second physical last-mile path is available. For mission-critical service, ask whether the design is single router, dual circuit single router, or dual circuit dual router, because Tekify's own SLA treats those differently.
A public assessment should not invent answers to those questions. It can say Tekify has a live, visible edge. It can say PeeringDB lists two exchanges and two Fremont facilities. It can say ARIN direct allocations and RIPEstat route visibility support the network identity. It cannot say every customer has two upstreams, two diverse fibres, two roof paths or guaranteed failover. That is the evidence-bound downgrade.
What fails first: access cut, radio site, power, congestion or repair queue
The main failure paths are all plausible, but they do not have the same public evidence. Access cut is plausible because Tekify sells fibre and Ethernet handoff, and because local fibre construction or building entry is always a physical exposure. Public sources do not show a Tekify-specific cut history, route map or construction-damage record. The failure path should therefore be described as a design risk, not as a known incident. If a fibre feeder to a wireless node or business park is cut and there is no diverse path, many users can lose service even if the public ASN remains announced.
Tower or radio-site outage is plausible because Tekify says it uses carrier-grade microwave wireless and customer-side wireless receivers. Public sources do not list towers, rooftops, relay sites or radio sectors. The assessment should not invent a tower map. It can say that radio-site power, line of sight, mounting, interference, weather, rooftop access and receiver health are part of the service chain where wireless is used. A wireless access design can be fast and useful, especially where fibre construction is slow; it can also concentrate many customers behind a shared powered node.
Upstream loss is supported more directly by routing evidence, but it appears less fragile than in truly thin cases. AS46886 is announced. RIPEstat sees multiple neighbours. PeeringDB lists exchange and facility presence. A total upstream black hole is not the obvious first risk. More plausible are partial route issues, exchange or transit degradation, congestion, or a customer-class path that depends on a smaller number of local feeders than the public edge suggests. That is still important because customers cannot see the boundary between their access segment and Tekify's upstream decisions.
Congestion is openly anticipated in the network-management disclosure. Tekify says acute congestion could result in slower upload, download and response times, with fair sharing among subscribers and special attention to real-time communication. That is not an admission of chronic oversubscription. It is a public statement about how the network would behave if demand exceeds available capacity. In a hybrid access network, congestion can appear in several places: a wireless sector, a fibre-fed aggregation node, an upstream port, an exchange peering link, customer Wi-Fi, a CDN path or the customer's own LAN. The public evidence does not isolate which is most likely for Tekify.
Field-repair shortage is the most human risk and the least publicly measurable. Tekify advertises rapid installation, professional installation, local support, on-call technician notification and business-hour reply expectations. It has a stronger support surface than many small providers. But the public record does not disclose crew depth, repair backlog, spares, contracted emergency labour, rooftop access processes or after-hours dispatch limits. The Basic SLA's repair window is explicitly limited to weekdays 9am to 5pm, while the Mission Critical SLA has a four-hour restoration target after ticket opening. Customers need to know which service tier they are buying.
Each failure path affects a different constituency. A residential customer may care most about remote work, streaming, school, Wi-Fi calling and household devices. A small business may care about point-of-sale systems, cameras, phones, VPNs, cloud applications and customer Wi-Fi. A temporary construction site may care about coordination, permits, safety communication and payment systems. A business using Tekify VoIP may feel even short congestion as voice-quality loss. A customer with static IPs for servers or cameras may feel route or power problems as inbound reachability loss. The same infrastructure incident can therefore be a nuisance for one account and a business interruption for another.
The policy conclusion is simple: Tekify's bill is an access-service promise, not just a retail commodity. When the system fails, the affected party is whoever depends on that local line as the first-mile path into the internet. The brand on the invoice is the party the customer calls, but the actual repair may involve fibre routes, wireless sites, building access, CPE power, upstream routing and field labour.
Evidence needed for a stronger rating
The evidence needed to upgrade Tekify from Medium to Strong is practical and company-specific. A public or customer-provided network map showing fibre-fed zones, wireless sectors, backhaul paths and facility handoffs would clarify which service claims are direct fibre, fibre-fed wireless or custom construction. A list of diverse upstreams, exchange ports, transit providers and failover policies would connect AS46886's visible routing to customer designs. A published IPv6 deployment note would show how the 2602:ffa4::/36 aggregate is used beyond registry visibility.
For access resilience, the most valuable facts would be route diversity by service tier. Does a mission-critical site receive two physically diverse circuits from separate entries? Does a residential wireless site have a redundant feeder? Are key radio nodes battery-backed, generator-backed or dependent on commercial power only? Are rooftop relays monitored, and what happens when a relay loses power? Are fibre cuts repaired by Tekify crews, contractors or third parties? Are spare radios, routers, optical modules and CPE stocked locally in Hayward or Fremont? These details determine whether the support promise is operationally strong or merely responsive.
For local labour, the useful facts would be service windows, after-hours dispatch policy, crew coverage by city, average response time by ticket type, restoration percentile, and whether the on-call technician can perform field work or only triage. Tekify's support page gives a reply expectation; it does not give a field restoration distribution. The Mission Critical SLA gives a target for qualifying dedicated internet; it does not publish how often the target is met. A small provider can outperform large incumbents because it is nimble and local. It can also be stretched by simultaneous outages. Public data does not settle that.
For capacity, the missing facts are peak utilisation, oversubscription policy, wireless sector loading, backhaul headroom, exchange-port utilisation, transit commits and CDN reach. The network-management disclosure says no data caps and flat-fee pricing, and it explains congestion handling. That is good transparency, but not a capacity audit. Buyers with high upload loads, hosted services, cameras, backup jobs or many VoIP users should ask for service-specific headroom and monitoring terms.
For authority and identity, the already visible record is satisfactory. The public site names Tekify, LLC for internet access in California and Tekify Fiber, LLC for telecom service-guide materials. ARIN names Tekify Broadband on AS46886 and multiple IP allocations. RIPEstat sees the ASN announced. PeeringDB lists Tekify Broadband Internet Services. CPUC documentation names Tekify Fiber in a certificate context. The remaining question is not whether the entity exists; it is how the retail brand, Tekify LLC, Tekify Fiber LLC, AS46886 and customer service tiers line up for each specific product.
The evidence-bound reading
TEKIFY-BROADBAND is stronger than a thin-footprint concern would suggest. It has the public attributes that matter for a regional ISP profile: a service site, a service area, residential and business offers, an address-check process, support channels, regulatory postings, ARIN number resources, announced BGP routes, IPv6 allocation, RPKI-valid route evidence, exchange listings and facility presence. Those facts justify keeping the assigned primary category company-region-global-type-regional-isp and the topics Regional ISP economics; Local support labour; Peering and transit.
The downgrade is narrower and more useful. Tekify's public record does not verify the physical diversity of the access plant. It does not show whether fibre drops, wireless relay sites, customer receivers, roof paths, building entries, business-park feeders and Fremont edge facilities are arranged in rings, spurs or single-route trees. It does not show tower or rooftop independence. It does not show battery runtime or generator coverage. It does not show field crew depth or spares. It does not show measured outage performance. It does not show which customers receive mission-critical designs and which receive basic or residential support.
That distinction is the central point. The bill can buy a real Tekify service. The internet can see a real Tekify ASN. A business can plausibly get a fast Ethernet handoff and a static IP. A household can plausibly receive fibre-backed wireless in a served neighbourhood. But resilience lives in the unglamorous parts: the roof receiver, fibre splice, radio-site power, building access, support ticket, spare router, exchange port, upstream route and person who can get to the failed point. Public evidence supports the operator. It does not yet prove the recovery chain.
For readers, the practical way to use the evidence is not to ask whether Tekify is "real." It is. Ask which Tekify design serves the specific address, whether the path is fibre, wireless or both, where the first powered dependency sits, what happens during a local power failure, which SLA tier applies, whether the route to AS46886 has a second physical path, whether after-hours field repair is included and whether the provider can show recent restoration performance. Until those answers are visible, the final grade remains Medium: credible network and service surface, with local resilience still address-specific and not fully proven by public sources.