The documentation is not very clear about what contributes to what with regards to Availability of different kinds:
Previously there was this schematic (see below) with some explanations. But I am not able to find this for 12.4
@Tarjei U. I'm pasting the answer from the doc space:
The HTTP errors of your choice (as defined in RUM Console) generally cause the failed operation to be classified as Failures (transport). Note however that Failures (TCP) have a higher priority and if both happen at the same time, a HTTP error will not be calculated as a Failure (transport) even if the AMD recorded it. This may be the reason why you see more incomplete responses than failures transport. You should also pay attention to the option controlling the classification. By default it is only for errors occurring in the base hit of the operation and for a monitored URL only (configured or auto-learned).
As far as the availability doc update, it is competing with other tasks, but still should be ready in a matter of weeks.
The only explanation I can think of is that 5 of the 8 incomplete responses caused the transport failures. The remaining three might have occurred outside the base hit or for a not monitored URL. It's only a speculation though, I'm about to consult the dev on it.
@Tarjei U., the development confirms this could be the case, so it seems I wasn't really speculating after all 🙂 On top of what I wrote before, you should also consider the fact that in the default configuration the only incomplete responses taken into account are 'Aborted response' and 'Aborted
response (standalone hit)' but only for the base hit + monitored url condition.