Saileelas Internet Service Private Limited makes a local connectivity bill depend on upstream routes and field repair

Summary

• Saileelas holds a Category C internet-service authorization for the Kalyan Secondary Switching Area, while its registered office, APNIC contacts and public business listing converge on Louiswadi in Thane. The licence establishes a local operating boundary, not a national footprint.
• Operating evidence is current and positive. AS149616 was visible on 10 July 2026, originated a 512-address IPv4 allocation and one IPv6 /48, and had valid route-origin authorizations. Saileelas also appeared as an operational Extreme IX Mumbai member at the exchange's Thane location.
• Capacity disclosures do not reconcile neatly. PeeringDB shows a 10 Gbps exchange interface and a self-reported 5-10 Gbps traffic range, while Extreme IX displays 3 Gbps for the member. Neither figure measures the customer's last mile, busy-hour throughput or restoration capacity.
• TRAI reported 463 broadband subscriptions at 31 March 2025, up from 424 a year earlier. Public reviews repeatedly allege outages and slow repair, but they are unverified customer signals rather than a representative performance audit. The missing facts are access topology, upstream contracts, physical path diversity, backup-power runtime, spare inventory and field-crew coverage.

A small subscriber number can carry a long dependency chain

The most revealing public number for Saileelas Internet Service Private Limited is not a headline speed. It is 463. In the Telecom Regulatory Authority of India's annual performance report for the year ended 31 March 2025, Saileelas appears with zero narrowband subscriptions and 463 broadband subscriptions. The relevant table is published at https://www.trai.gov.in/sites/default/files/2025-07/YIR_08072025.pdf. A TRAI dashboard for the previous year showed 424 broadband subscriptions at https://www.trai.gov.in/sites/default/files/2024-12/telecom-dashboard_compressed.pdf. On those two official snapshots, the reported base grew by 39, or about 9.2 per cent.

That scale is large enough to prove that this is more than a paper registration. It is also small enough for physical and human bottlenecks to matter immediately. One aggregation switch, one shared building uplink, one damaged distribution cable, one unavailable splicing technician or one saturated upstream handoff can affect a meaningful fraction of the base. A national carrier can distribute a failure across layers of regional operations. A local provider may instead depend on a compact inventory, a small number of people who know the routes, and access permission at each building or roadside cabinet.

The customer's invoice compresses those dependencies into a monthly service. It does not identify who owns the duct, pole, roof route or building riser. It does not say whether an advertised speed is limited by the access line, the local aggregation point, internet transit, public peering or the customer's Wi-Fi. It does not state how long batteries last at the local node, whether two upstream sessions travel through different ducts, or how many simultaneous cuts the field team can handle after heavy rain or road work.

Saileelas therefore deserves analysis as a chain rather than as an ASN or licence holder alone. The chain begins at a customer's router and premises equipment, crosses a building or street access segment, reaches aggregation and the provider's routing edge, and then exits through paid transit or peering. The weakest indispensable segment sets the practical service level. A healthy route announcement cannot repair a severed drop cable. A pristine fibre into a building cannot reach the internet if the routing edge loses every usable upstream. A spare upstream cannot help if both circuits share one physical entrance.

The legal footprint is Kalyan, not "Global"

The article's classification uses the publication's global regional-ISP category, but Saileelas's legal service area is much narrower. The Department of Telecommunications' current list identifies authorization DS-11/211/2021-DS-III as Category C for Kalyan, signed and effective on 31 December 2021. Saileelas appears in the current document at https://www.dot.gov.in/static/uploads/2026/03/1583eeb1e6fe5cf8a56110195d8320e9.pdf. The January 2025 list records the same authorization, category, service area and Louiswadi address at https://www.dot.gov.in/static/uploads/2025/07/ccc9dee71e76157f049d2ae5b8d0911b.pdf.

Category C has a specific regulatory meaning. The Department says at https://preprodeservices.dot.gov.in/internet-service that Category A covers the national area, Category B covers a telecom circle or metro area, and Category C covers a Secondary Switching Area. The Unified Licence text at https://www.dot.gov.in/static/uploads/2026/05/af70ec29b07b112cdc5475d80afe8222.pdf uses the same boundary. Saileelas should thus be understood as a Kalyan-area licensee, even though “Kalyan” in licensing administration is not a promise that every address in that area is connected or orderable.

Several public records centre the company in Thane. APNIC's registration for AS149616 lists a Louiswadi, Thane address and names Saileelas at https://rdap.apnic.net/autnum/149616. The registration for its IPv4 allocation uses the same address at https://rdap.apnic.net/ip/103.186.46.0/23. A Department of Telecommunications registration-certificate list issued in 2026 again shows Shop No. 20, Jeevan Prakash, Louiswadi, with Nilesh Suresh Vaity as the named representative at https://www.dot.gov.in/static/uploads/2026/04/3f33a7054c5cb484c831d2ae5b8d0911b.pdf.

Commercial corporate records provide supporting, not primary, evidence. Zauba Corp identifies CIN U64203MH2020PTC346685, an incorporation date of 25 September 2020, an active status and directors Vidya Nilesh Vaity and Nilesh Suresh Vaity at https://www.zaubacorp.com/company/SAILEELAS-INTERNET-SERVICE-PRIVATELIMITED/U64203MH2020PTC346685. The Company Check gives the same incorporation date, Thane base and active status at https://www.thecompanycheck.com/company/saileelas-internet-service-private-limited/U64203MH2020PTC346685. Those pages help connect the legal company to the network records, but they do not disclose active kilometres of cable, tower sites, operating expenditure or customer churn.

The routing edge is real and currently visible

Saileelas controls an autonomous-system number, AS149616. APNIC registered it on 8 April 2022 under the name SAILEELAS-AS-IN. The public record was last changed in September 2025 and remained active when checked for this article. The associated IPv4 allocation is 103.186.46.0/23, a block of 512 addresses. The registration describes it as allocated portable address space. That matters because provider-held portable space can be originated through different connectivity arrangements without renumbering every endpoint, subject to routing policy and contracts.

Public route collectors show active use rather than dormant ownership. RIPEstat's routing-status view at https://stat.ripe.net/data/routing-status/data.json?resource=AS149616 recorded the first observed announcement on 27 April 2022 and a latest observation on 10 July 2026. It counted three visible IPv4 announcements covering 512 addresses and one IPv6 /48. At that observation time, 326 of 327 available IPv4 RIS peers saw the route. The IPv6 route was seen by 15 of 321 peers, a much smaller fraction that cautions against treating IPv6 reachability as equivalent to IPv4 reachability everywhere.

The announced-prefix view at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS149616 listed the aggregate 103.186.46.0/23, its two /24 components and 2001:df2:99c0::/48. Announcing the aggregate and more-specific routes can support traffic engineering, but the public table alone does not reveal why the /24s are present, whether they take different physical paths, or whether one is reserved for recovery. A route is a reachability instruction, not a fibre map.

Route-origin security is one of the stronger technical signals. RIPEstat's validation check for 103.186.46.0/23 at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS149616&prefix=103.186.46.0%2F23 found a valid authorization for AS149616 with a maximum length of /24. The IPv6 /48 was also valid at https://stat.ripe.net/data/rpki-validation/data.json?resource=AS149616&prefix=2001:df2:99c0::%2F48. APNIC explains at https://www.apnic.net/community/security/resource-certification/ that a Route Origin Authorization specifies which ASN may originate a prefix. Valid authorization reduces exposure to some accidental or malicious origin errors. It does not verify the rest of the AS path, protect a local cable, or guarantee that every neighbouring network rejects invalid routes.

The routing evidence earns a clear positive finding: Saileelas operates a visible network identity, uses its registered address resources and has taken a concrete route-origin protection step. The evidence does not disclose routers, software, site count, edge geography, failover timing or staff coverage. It also does not prove that every one of TRAI's reported subscriptions uses Saileelas's own address block; some users could sit behind address translation or other arrangements.

The Thane exchange attachment improves reach, but does not settle transit diversity

Saileelas is an operational member of Extreme IX Mumbai. The exchange's member page at https://extreme-ix.org/members/peers?location=mumbai lists AS149616, a February 2026 joining date, route-server participation, a location labelled Thane and displayed capacity of 3 Gbps. That is unusually useful location evidence. It connects the routing identity to a shared interconnection platform in the same urban area as the company's registered office.

PeeringDB supplies a second view at https://www.peeringdb.com/net/41616. Its entry identifies Saileelas as a cable, DSL or ISP network, gives an open peering policy, marks both IPv4 and IPv6 as operational on Extreme IX Mumbai, and shows exchange addresses 103.77.109.9 and 2001:df2:1900:2::49. The interface speed is shown as 10,000 Mbps. PeeringDB also contains a self-reported traffic range of 5-10 Gbps, 12 IPv4 prefixes and four IPv6 prefixes. Those values were recently maintained, but they are operator-supplied descriptors rather than an independent measurement of carried traffic.

The 3 Gbps and 10 Gbps figures should not be forced into a false agreement. One may describe committed or displayed member capacity while the other describes an interface rate. The exchange could shape service below physical port speed, multiple arrangements could be represented differently, or one page could lag a commercial change. The public pages do not explain the difference. The responsible conclusion is that Saileelas has a live exchange attachment with at least a multi-gigabit disclosed scale, while exact usable exchange capacity is unresolved.

Neither number is total internet capacity. Public peering lets two networks exchange traffic directly or through route servers, often improving latency and reducing paid-transit load. It does not necessarily supply a default route to every destination. A local ISP still needs comprehensive reachability, typically through one or more transit providers, unless its peering set somehow covers the entire internet, which this evidence does not suggest.

RIPEstat's neighbour view at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS149616 saw four AS adjacencies on 10 July 2026: Radan Tech Networks' AS153734, ONEOTT's AS17665, F5's AS35280 and Sify's AS9583. Their registrations can be read at https://rdap.apnic.net/autnum/153734, https://rdap.apnic.net/autnum/17665, https://rdap.db.ripe.net/autnum/35280 and https://rdap.apnic.net/autnum/9583. An observed adjacency is not a disclosed commercial relationship. Some may be peers learned through an exchange, some may carry transit, and the visible path can change by collector. The four names prove routing contact, not four independent upstreams.

Four route neighbours can still share one trench

Logical diversity and physical diversity answer different questions. If Saileelas can reach a destination through more than one neighbouring network, it may route around a remote policy failure or a failed session. If all those connections enter the same Thane facility over the same leased access circuit, a backhoe cut or building-power failure can remove them together. If two circuits terminate on one edge router, a router fault can defeat both. If the exchange route server is the common means of learning peers, a route-server problem can affect many sessions even when the physical port stays up.

PeeringDB's Saileelas entry lists no private interconnection facility and no additional public exchange. That absence does not prove there is no second facility: operators do not always disclose every commercial handoff. It does mean a reader cannot verify a second interconnection site from that record. The Extreme IX exchange itself spans several Mumbai-region facilities, listed at https://www.peeringdb.com/api/ix/1627, including facilities in Thane, Kalyan, Mumbai and Navi Mumbai. Saileelas's own member record points to Thane, but it does not identify a second exchange location or a second physical port.

Even the phrase “Thane location” needs discipline. The exchange list identifies Extreme Thane at Dev Corpora near Cadbury Junction. The Saileelas member page says Thane. It is reasonable to connect the member to that exchange location, but the record does not disclose the rack, carrier, fibre path, power feed or router. It certainly does not establish that the route from Louiswadi to the exchange avoids every shared road corridor or utility dependency.

The useful redundancy test has several layers. First, are there two default-capable upstreams under separate contracts? Second, do they terminate on separate routers, power supplies and exchange or carrier facilities? Third, do the access circuits follow geographically separate paths and enter the site through different ducts or building risers? Fourth, are both paths loaded lightly enough that either can carry essential traffic when the other fails? Fifth, has failover been observed under peak conditions rather than assumed from configuration?

None of those answers is public. The four observed neighbours make complete single-neighbour dependence less likely than it would be with only one adjacency. The live exchange port provides a credible path to local content and networks. But the available record cannot establish two physically independent default routes. Saileelas should therefore receive credit for interconnection activity without receiving an unearned resilience claim.

Installed capacity is not the capacity customers can use

Capacity figures can look generous when divided by 463 subscriptions. Three gigabits per second divided evenly would be roughly 6.5 Mbps per reported subscription; ten gigabits would be about 21.6 Mbps. Those calculations are mathematically correct and operationally misleading. The exchange attachment may carry only peered traffic, while paid transit uses a separate interface. The subscriber count is from March 2025 and may have changed. Demand is not simultaneous or equal. Some subscriptions may be business lines, some residential, and some may use private addressing. A port rate says nothing about the access link into a particular building.

The self-reported 5-10 Gbps traffic range is also not a busy-hour chart. It gives an order of magnitude, not a time series. It cannot reveal whether traffic reaches that range briefly, whether capacity is symmetric, whether a transit circuit saturates before the exchange port, or how much headroom remains during a failure. PeeringDB's reported 12 IPv4 and four IPv6 prefixes do not match the four globally visible announcements in the RIPEstat snapshot, which is another reminder that profile fields and route collectors describe different things.

For customers, usable capacity is the minimum available along the path at the time they need it. A 100 Mbps retail plan can be constrained by a 1 Gbps building uplink shared among many households, by a passive optical split, by a fixed-wireless sector, by an overloaded aggregation link, by internet transit, by a content server, or by Wi-Fi inside the flat. The public business listing at https://www.justdial.com/Thane/Saileelas-Internet-Service-Pvt-Ltd-Near-Union-Bank-Of-Indialouiswadi-Louis-Wadi-Thane-West/022PXX22-XX22-190420131048-K8S5_BZDET describes broadband, Wi-Fi and leased-line services, but it does not publish a verifiable current plan matrix or network design.

The clean way to settle capacity would be anonymised peak-hour utilization by layer: access aggregation, each backbone circuit, transit, public peering and the broadband gateway. A failover test should show utilization after one path is removed. Customer measurements should separate Ethernet throughput at the provider demarcation from in-home Wi-Fi. No such current figures are public. Saileelas may have ample headroom; the disclosed port and traffic bands simply cannot demonstrate it.

The last mile remains the largest physical unknown

Saileelas's licence, address registrations and business listing establish a local broadband operator. They do not establish whether the access plant is fibre to the home, Ethernet over local cable, fixed wireless, leased capacity from another network, or a mixture. The Department's general page notes that Indian ISPs may use fibre, DSL and wireless technologies, but that is a statement about the authorization class, not a description of Saileelas's deployment.

The distinction changes every failure calculation. In a passive optical network, a feeder fibre may serve several splitters and many premises. A single cut close to the optical line terminal can remove a large branch. Farther downstream, a distribution or drop cut has a smaller blast radius. Passive splitters do not require local power, but active cabinets, aggregation switches and optical terminals do. Restoration depends on spare cable, closures, connectors, optical test equipment, splicing skill and access to the damaged route.

In an active Ethernet layout, switches placed in buildings or street cabinets need power and environmental protection. Their uplinks may form a ring or may simply daisy-chain. A ring can recover from one cut only if both directions are connected, configured and sized for the displaced traffic. Two fibres in the same sheath are not diverse. A switch with dual power inputs is not protected if both supplies use the same failed circuit.

Fixed wireless shifts part of the access risk to line of sight, interference, tower or roof access, radio alignment and power at both ends. It may speed deployment across a dense urban edge, but a sector outage can affect many customers at once. A point-to-point wireless backhaul may avoid a road trench while creating a common tower or weather dependency. The available public records do not let readers choose among these architectures for Saileelas.

Right-of-way rules shape repair whichever medium is used. India's Telecommunications (Right of Way) Rules, effective from 1 January 2025 and published at https://eservices.dot.gov.in/sites/default/files/2024-11/Notified_RoW_Rules_18_09.pdf, define ducts, common conduits and permissions for telecommunications lines. Maharashtra issued its implementation decision at https://eservices.dot.gov.in/sites/default/files/circular-notifications/Maharashtra_Telecommunication%20ROW%20Rules%202024%20GR%205.2.2025.pdf. Formal permission can make deployment more predictable, but it does not eliminate emergency coordination with road authorities, housing societies, landlords and other utilities.

Failure path one: an access segment is cut or disconnected

An access cut is the most literal way for a local bill to lose value. Road excavation can damage a feeder. Building work can sever a riser. A connector can be disturbed in a shared cabinet. Water can enter a closure. A cable can be removed during facade work. If the service uses radio, a shifted antenna or failed power injector can create the same customer result without a cable cut.

The first operational question is localization. Can the provider see the failure from the network centre, distinguish one premise from a building or area outage, and identify the last known healthy node? Optical power readings, switch alarms and customer-device telemetry can reduce diagnosis time. They do not replace a site visit when the physical path is damaged. The second question is access: can a technician enter the building, roof, cabinet or roadside work area when the fault occurs? A perfectly staffed provider can still wait on keys, permits, safety conditions or a landlord.

The third question is restoration material. Fibre repair requires compatible cable, closures, splice trays, connectors and test gear. Wireless repair may require the right radio, mount, power supply and configuration. Customer-premises replacement requires stocked optical terminals or routers and a way to restore credentials. A spare that exists at a distributor across the city is not equivalent to a labelled spare in the local store.

The fourth question is route knowledge. Small networks often contain paths added building by building. Accurate geographic records and labelled fibres matter when the technician who installed a line is unavailable. Public information does not show whether Saileelas maintains route maps, spare counts, alternate paths or restoration targets. That is not evidence that it lacks them; it is the principal missing evidence behind any claim of quick repair.

The new right-of-way regime may help with planned deployment and formal coordination, but emergency restoration still meets physical reality. If a road project cuts two nominally separate lines in one trench, contractual diversity disappears. If a building disconnects power to a common switch, every downstream line can look intact while service remains absent. The relevant service promise is therefore not “fibre” or “wireless.” It is the measured time from fault recognition to restoration under the failures the local plant actually experiences.

Failure path two: power disappears at a common node

Every active stage requires electricity: the customer's router and optical or wireless terminal, any powered building switch, local aggregation, the broadband gateway, edge routers and interconnection equipment. An outage at the customer premises is visible but limited. An outage at a shared building or neighbourhood node can disconnect many subscriptions. An outage at the routing edge or the exchange access node can preserve local lights while removing internet reachability.

Backup power needs a stated load and duration. A small uninterruptible supply can bridge a short interruption, but battery runtime falls with age, heat and added equipment. A generator requires fuel, maintenance, safe exhaust and someone able to reach it. Dual utility feeds provide little protection if they share a substation. A powered router at the edge is of limited value if the access switch or leased fibre provider loses power elsewhere.

No public Saileelas page describes batteries, generator support, runtime, remote power alarms or priority restoration. PeeringDB does not list a Saileelas facility, so the power arrangement at its edge cannot be read from a disclosed colocation site. Extreme IX's operational status confirms that the exchange attachment was functioning at the observation point; it does not promise continuity during a local utility incident.

The right resilience questions are concrete. Which nodes are active and how many customers depend on each? What is the tested battery runtime at normal and peak load? Which sites have generator connections? Who receives a low-battery alarm? Can a crew reach the site during flooding or traffic restrictions? Does a leased backhaul supplier have equal or longer reserve power? Are replacement batteries and power supplies locally available?

Customers have their own boundary. A provider may keep its plant online while a flat loses power to the router. For home workers, shops and small offices, a modest local battery can preserve service only if the provider's path also remains powered. Saileelas could make that dependency legible by publishing customer-device power requirements and the scope of network backup. In the absence of that information, power resilience remains unverified at both ends.

Failure path three: the route survives locally but loses a usable upstream

BGP can move traffic around some failures, but only among paths that remain available and suitable. If a transit session drops, routes learned from another provider may take over. If a public exchange fails, paid transit may carry traffic previously exchanged locally. If a more-specific route is withdrawn, an aggregate may preserve reachability. Each recovery consumes spare capacity and depends on policy being tested before an incident.

Saileelas's four observed neighbours are encouraging because they show more than one routing contact. The active Extreme IX session is also useful. Yet the public record does not identify which neighbour supplies full transit, whether there are two default-capable providers, or whether the paths terminate independently. F5 is a large content and security network with broad peering, while Sify, ONEOTT and Radan Tech have different regional roles. Their presence in an AS path should not be converted automatically into four transit contracts.

Route-origin validity protects a different layer. The valid IPv4 and IPv6 authorizations tell networks using route-origin validation that AS149616 is permitted to announce those prefixes. They do not stop a legitimate upstream from suffering a fibre cut, a router failure or congestion. They do not attest to path diversity. They also cannot prevent a configuration error inside Saileelas from withdrawing all routes.

Recovery should be judged by observed convergence and customer impact. How long does it take for an alternate path to become usable? Does address translation preserve sessions? Does DNS remain reachable? Does the surviving link have enough capacity for the evening peak? Are important local networks still reachable directly, or does traffic take a long transit path? The difference between a route returning in seconds and applications recovering cleanly can be substantial.

RIPEstat's near-complete IPv4 visibility is a strong current signal, while its much lower IPv6 peer visibility calls for closer examination. The difference may reflect collector topology rather than customer failure, so it should not be treated as an IPv6 outage. It does justify asking for end-to-end IPv6 reachability tests from multiple networks, the intended routing policy and whether IPv6 receives the same failover attention as IPv4.

Failure path four: the network stays up but becomes too congested to use

Congestion is a partial failure. Lights remain on, routes remain visible and basic tests may pass, but video calls break, downloads slow and interactive services become erratic. It often appears at the busy hour, which makes an average utilization figure a poor defence. It can also emerge during failover when two normally separate traffic loads move onto one surviving circuit.

The mismatch between the exchange's displayed 3 Gbps and PeeringDB's 10 Gbps interface is especially relevant here. A 10 Gbps port can still carry only a smaller commercial allocation. A 3 Gbps exchange commitment can coexist with additional transit elsewhere. Neither discloses peak utilization. The 5-10 Gbps traffic band suggests a network operating at a multi-gigabit order of magnitude, but without a measurement period it cannot be used to calculate headroom.

Access congestion may occur far below those numbers. If one building has a shared uplink, its residents can see slow service while the edge has abundant capacity. If one wireless sector is heavily loaded, another sector may be idle. If a passive optical split is designed too aggressively, optical margins and shared bandwidth can constrain users. Saileelas does not publish the split ratios, sector loads, building-uplink rates or contention policy needed to assess these possibilities.

TRAI's quality framework makes the distinction between advertised access and operational performance important. The 2024 Standards of Quality of Service regulations are published at https://trai.gov.in/node/13235. TRAI's performance tables separately consider fault restoration, bandwidth utilization, connection speed, availability, packet loss and latency; an example quarterly report is at https://www.trai.gov.in/sites/default/files/2024-11/QPIR_22072024%20%281%29.pdf. Those are distinct dimensions because no single speed label captures them.

For Saileelas, a credible capacity account would show the 95th percentile and peak utilization for each constrained link, packet loss and latency during the busy hour, and performance with the largest path unavailable. It would also explain whether the 463 subscriptions are concentrated in a few buildings or distributed across many neighbourhood nodes. Until then, current route visibility and port disclosures demonstrate operation, not guaranteed customer experience.

Failure path five: field repair becomes the bottleneck

Physical networks are repaired by people. A local provider needs someone to receive and classify a complaint, someone with remote visibility, and someone able to reach the fault with the right parts and permissions. During a single-premises failure, one technician may be enough. During a storm, road project or common feeder cut, the same team can face many simultaneous cases. Queue depth then becomes part of network resilience.

Saileelas does not publish field staffing, operating hours, contractor support, mean time to repair or spare inventory. The PeeringDB contact is a network-operations contact using a Space Infoway address, which may indicate outside operational support or a shared technical contact. It cannot establish who dispatches local crews, how many are available, or whether remote routing support and physical repair belong to the same organization.

The public customer listing offers an unofficial signal. Justdial showed hundreds of aggregated ratings when reviewed, along with comments spanning several years. Multiple negative comments allege recurring disconnections, difficulty reaching support, shortages or delays involving technicians, and restoration taking several days. The same listing also summarizes some positive mentions of quick resolution and low downtime. The page is visible at https://www.justdial.com/Thane/Saileelas-Internet-Service-Pvt-Ltd-Near-Union-Bank-Of-Indialouiswadi-Louis-Wadi-Thane-West/022PXX22-XX22-190420131048-K8S5_BZDET.

Those reviews cannot be treated as a performance sample. The platform does not reveal the denominator of all repairs, verify every reviewer as a customer, establish which comments refer to the incorporated company rather than an earlier local trading name, or control for unusually motivated complaints. Old comments may describe a network before the ASN, current licence or 2026 exchange connection existed. They are not proof of present failure rates.

They do, however, identify a recurring question that fits the physical risk: how quickly can the operator restore a local line? The signal would be settled by monthly fault counts, the share repaired by the next working day and within three working days, outage minutes by cause, repeat-fault rates, abandoned-call rates, crew rosters and escalation records. In their absence, the reviews justify scrutiny of repair capacity, not a verdict that every current customer receives poor service.

Regional ISP economics reward compactness and punish idle resilience

A 463-subscription provider faces an unforgiving cost structure. Revenue scales with paying lines. Many resilience costs arrive in chunks: a second upstream, a spare edge router, another exchange port, a generator, optical test equipment, a splicing kit, inventory and an additional technician. The next layer of protection may cost much more than one customer's monthly payment even though it protects the entire base.

Compact geography can help. Shorter travel distances can make local repair faster. Familiarity with housing societies and building routes can improve diagnosis. A local provider can add customers near existing plant rather than extending a long feeder for each one. Public peering in Thane can keep some traffic local and reduce dependence on paid transit. Portable address space and a valid routing identity give the operator options when negotiating connectivity.

The same compactness concentrates risk. Customers clustered behind one aggregation point create efficient utilization until that point fails. A small number of staff can know the network intimately until two faults occur at once or a key person is unavailable. One exchange location can provide excellent local reach until the access circuit to it is cut. An annual prepaid plan can improve cash flow but raises the customer's exposure if restoration is weak; some public reviews specifically complain about difficulty after paying for long periods, though those allegations remain unverified.

Growth from 424 to 463 reported broadband subscriptions is positive but modest. It does not show revenue, retention or profitability. It also predates the February 2026 Extreme IX joining date. The interconnection upgrade may have been intended to improve cost, performance or resilience, but no public announcement explains its purpose or customer effect. It would be premature to credit the exchange connection with the earlier subscriber growth.

The economic question is therefore not whether redundancy is “worth it” in the abstract. It is which common failures dominate customer minutes lost and which protection produces the largest reduction. A second logical transit provider may be less valuable than a physically separate access circuit. A generator may be less valuable than replacing ageing batteries at many building nodes. One more field technician may improve restoration more than a faster edge port. Without outage-cause and utilization data, outsiders cannot rank those investments for Saileelas.

Who loses when one link in the chain fails

TRAI's 463 subscriptions are accounts, not necessarily 463 people. A residential line can support a household. A business line can support employees, customers, payment terminals, cloud applications and security systems. A housing-society uplink can aggregate many users. The affected population during a common failure can therefore be larger than the subscriber number suggests.

The impact mechanism varies. An access cut removes one building or street even if the global route remains healthy. A power failure at a shared switch can create the same footprint. An upstream loss can affect the entire network or only destinations reached through that path. Congestion degrades delay-sensitive uses first, including calls, remote work and interactive transactions. Slow dispatch lengthens all of those effects.

Local support is part of the product because customers cannot usually identify the failing layer. A red optical light, a router that has lost authentication, an exchange incident and an upstream route leak may all be reported as “internet down.” The provider must translate the symptom into a fault domain and communicate an expected restoration time. Silence or repeated generic responses increase the cost to the customer even if the technical repair time is unchanged.

The quality rules give this an external frame. TRAI's 2024 regulations apply to broadband providers and require measurement of service performance at the authorized service-area level. A September 2024 direction at https://www.trai.gov.in/sites/default/files/2025-05/Direction_19092024.pdf discusses live monitoring of network availability and reporting. Regulatory compliance data, if published at a useful provider level, would be more representative than review comments. The public material reviewed for this article did not expose a current Saileelas-specific quality table.

This absence should not be converted into non-compliance. Small providers can be present in aggregate filings without a readily indexed individual row. The proper conclusion is that customer impact is plausible and material, while measured Saileelas restoration and availability remain unavailable in the public pages cited here.

What a credible redundancy account would contain

Saileelas has enough verified operation to make a detailed resilience account possible. It would begin with the physical access layer: the technologies used, the neighbourhoods or buildings served, each common aggregation point, the number of subscriptions behind it and whether alternate paths exist. Exact customer addresses need not be exposed. Aggregated failure domains would be sufficient.

The next layer is interconnection. The operator could identify the number of default-capable upstreams, the number of exchange ports and the facilities in which they terminate. It could state whether last-mile carrier circuits follow separate routes and enter through separate ducts. Commercial prices and sensitive routing policy could remain private. The central claim to substantiate is whether one physical incident can remove all external reachability.

Power evidence should include normal load, battery runtime under that load, generator coverage, fuel or recharge arrangements and the date of the last test. A photograph of a battery cabinet would not be enough. Runtime and successful transfer under load are what matter. The same standard applies to spare equipment: counts, compatibility and replacement time are more useful than a generic assurance that spares exist.

Field recovery should include support hours, dispatch coverage, the number of trained fibre or wireless technicians available in the service area, contractor arrangements for surge events and performance against restoration targets. The most informative table would separate single-customer faults, building or neighbourhood incidents, backbone cuts, power failures and upstream events. Median repair time alone can hide the long incidents that cause the greatest harm.

Capacity should be shown as usable headroom, not summed port labels. Peak-hour utilization on access, transit and peering links; packet loss and latency; and the result of a one-path-down test would make the 3 Gbps, 10 Gbps and 5-10 Gbps disclosures intelligible. IPv4 and IPv6 should be tested independently because the current public visibility differs sharply.

Finally, public status communication matters. A reachable status page with incident start time, affected area, fault class and restoration updates would let customers distinguish a home problem from an area failure. PeeringDB currently shows no Saileelas status-dashboard URL. The company's web domain returns access and certificate problems from outside checks, while the PeeringDB profile still points to it. A working public service page would not prove reliability, but it would improve the recovery experience and provide a current operating signal beyond third-party listings.

Operating-status assessment: active network, incomplete resilience proof

Saileelas should not be downgraded to a merely historical or nominal operator. The evidence is too current and too specific for that. The Department of Telecommunications included its Kalyan Category C authorization in 2026. APNIC shows active number resources. RIPE RIS saw the ASN and prefixes on 10 July 2026 with nearly complete IPv4 visibility. Both IPv4 and IPv6 origins were valid under RPKI. Extreme IX listed an operational Thane member connection joined in February 2026. TRAI counted hundreds of broadband subscriptions at the last identified annual reporting date.

Those facts establish legal authorization, customer operation and a live internet edge. They also narrow the uncertainty. The remaining gap is not whether Saileelas has ever operated. It is whether the access and recovery design can keep a paying customer connected through a realistic local failure.

The public record does not reveal the access medium, feeder map, ring topology, node power, backup runtime, spare inventory or crew coverage. It does not reconcile the exchange's 3 Gbps display with PeeringDB's 10 Gbps interface and 5-10 Gbps traffic band. It shows four observed neighbours but not two physically separate, default-capable upstream paths. It contains persistent negative review signals about outages and repair, but no representative Saileelas quality report with which to confirm or reject them.

The appropriate network evidence grade is therefore Medium. Saileelas has stronger operating evidence than many small local providers: a current licence, independently visible routes, protected origins, recent exchange participation and regulator-reported subscriptions. It lacks the physical and service-performance disclosure required for a strong resilience finding.

That distinction matters to anyone buying the service. The route can be healthy while a building line is cut. A multi-gigabit port can coexist with a congested access segment. Four BGP neighbours can share one facility. A battery can exist without lasting through the incident. The final quality of the connection depends on the least visible parts of the chain: local plant, power, physical path diversity, parts and labour.

Saileelas's next convincing public evidence would not be a larger speed number. It would be a map of failure domains without customer details, a reconciled capacity statement, two demonstrably independent external paths, tested backup-power runtimes, current provider-level quality results and restoration performance by fault class. Those items would show whether a small Kalyan-area network has turned visible internet reachability into a service that recovers when the street-level infrastructure fails.