That page gives you a good picture of what repeaters are good enough (RF wise) to be used for routing on the first hop to the rest of the mesh. You want to see one or more repeaters with strong bidirectional links to the hub. Ideally, they will be stable so that routing paths also remain stable.
There's two ways of looking at the info here and they corroborate each other since this page reports link status as well as recently used first hop routers: repeaters with low nonzero cost figures (shown in the Neighbor Table) should be the repeaters actively being chosen for routing (shown in the Route Entry section).
It's easy to see which repeaters have been used recently from the Route Table entries, which show Outlets 11, 12, 19, 20 and 26 as the first hop 'vias' being used to send messages.
From this you'd deduce that the other repeaters aren't as active (at least in the timeframe the page was captured; if a route hasn't been used recently, a new route request is generated and route table entries may change).
The inCost/outCost figures give you a clue as to why the other repeaters aren't being used. For example, the link to Outlet 5 has a very weak signal at the hub's receiver (hub reported low LQI on this link, resulting in high inCost) and outbound at Outlet 5's receiver (Outlet 5 reported high outCost; from this we can infer that Outlet 5's LQI is low). Similar story for the unused repeaters; Zigbee's routing strategy favors low 'cost' routes so it will pick repeaters with good bidirectional reception (link costs get ranked in order of best =1, poorest=7; with 0 meaning no status/unusable).
So as of the time of that snapshot, outlets 11, 12, 19, 20 and 26 are your key repeaters. Their status gets reported roughly every 15 seconds; if conditions change (signal blockage, interference, HW failure) , the hub may change routing to use a better repeater if one is available. If there's no viable repeaters (or only ones with poor cost figures), communication issues result.
The destination devices (the nulls followed by short ID's in the Route Table section) would normally be showing their assigned name instead of null. As the short ID's change with every rejoin (and eventually get re-associated to their assigned name), it looks like many of these have been recently rejoined; probably they are the end devices that were previously child devices of the hub.... now they are child devices of the repeaters elsewhere in the mesh. The nulls should be replaced by the device's assigned name after a while if things are stable.
If you're not seeing issues with your end devices or repeaters, you don't need to worry about the repeaters showing poor cost figures; the mesh is finding a useable path in spite of them. If you are seeing issues (can't reliably send commands or see correct status on the device page) you should probably try to improve the mesh (by relocating marginal repeaters or adding an intermediate repeater somewhere in between).
If you are having issues with mesh stability (the devices in the neighbor table change significantly within a short amount of time, nulls always showing instead of device names) something else is going on... that's when you'd be looking at the environment (for interference) or possibly a flaky device.
