1. Network reach and routing table depth
A transit provider's routing table is the list of destinations it can forward traffic to. A provider with limited exchange presence or few upstream peers will have gaps in its table, meaning traffic to those destinations has to take a longer or less optimal path. The practical question is not “how many prefixes do you announce?” but “how do you reach these five destinations that are critical to my users?”
Two signals that proxy for routing table quality without requiring a full BGP audit: IPv4 block size (larger allocations generally correlate with deeper peering relationships) and internet exchange presence count (more exchanges means more opportunities for short-path peering). Both are publicly verifiable through RIR data and PeeringDB.
2. Route diversity and redundancy
Single-provider transit is a single point of failure. Most serious buyers run two transit providers with different upstream paths and use BGP to load-balance or failover. When evaluating a provider for a redundant setup, ask specifically how their upstream peering differs from your existing provider. Two providers that both buy most of their transit from the same backbone carrier give less redundancy than their separate logos suggest.
Useful question: “Which autonomous systems are your primary upstreams, and what percentage of your traffic goes through each?” A provider reluctant to answer that has probably not thought it through themselves.
3. Latency to your key destinations
Transit latency is not a single number. A provider may be excellent to destinations in Western Europe and slow to Southeast Asia, or vice versa. The only reliable test is to measure. Ask for a test account or a trial circuit, run traceroutes to ten destinations that matter to your workload, and compare the hop counts and round-trip times with your current provider. Focus on the median, not the best case.
Exchange presence geography is a shortcut for this test when you cannot get a trial. A provider present at DE-CIX, AMS-IX, LINX, and Equinix IX will generally have short paths to Western European destinations. A provider with heavy presence in APNIC-region exchanges will be strong to that market. The viabandwidth directory surfaces exchange presence count per carrier.
4. SLA terms and what they actually cover
Transit SLAs typically cover uptime (availability of the physical circuit), packet loss, and latency thresholds. They do not typically cover routing issues, BGP convergence time, or performance to specific destinations. Read the definitions section: “uptime” is often defined as circuit availability, not end-to-end reachability. A circuit can be up while BGP is flapping and traffic is blackholed.
The practically important SLA clauses are mean time to respond (MTTR) for outages, the escalation path when NOC tier-1 cannot resolve the issue, and the credit mechanism. Some providers credit only the prorated cost of the outage window; others credit a multiple. The credit is often harder to collect than the contract implies.
5. Pricing structure and commit terms
Internet transit is almost universally billed on 95th-percentile sampling of a five-minute interval over a monthly billing period, with a minimum commit. The 95th percentile means the top 5 percent of your traffic peaks are not charged, which rewards bursty but predictable profiles. Committing to a higher minimum in exchange for a lower per-Mbps rate is the standard negotiation lever; the right commit level is usually 60 to 75 percent of your actual average utilisation.
Watch for: overage rates (traffic above commit billed at a flat or a multiplied rate), port fees charged separately from bandwidth, and whether the contract allows downgrades at renewal or locks you in for the full term.
6. NOC quality and escalation path
A transit provider's value disappears during an outage if you cannot reach an engineer who can actually fix it. Before signing, call the NOC at an off-hours time with a test question. Note how long it takes to reach a human, whether they understand BGP, and whether they can pull routing table data in real time. A NOC that routes every question through a ticket queue and promises a response in four hours is not the right partner for a latency-sensitive workload.