Currently power_LoadTest provides some detail of success/failure of page loads in the form of these keyvals:

ext_audio_failed_loads{perf}=29_71_0_71_4_71_71_37
ext_audio_successful_loads{perf}=1_0_1_0_1_0_0_1
ext_docs_failed_loads{perf}=0_0_0_0_0_0_0_0
ext_docs_successful_loads{perf}=6_6_6_6_6_6_6_6
ext_email_failed_loads{perf}=0_0_0_0_0_0_0_0
ext_email_successful_loads{perf}=3_3_3_3_3_3_3_3
ext_status{perf}=good_good_good_good_good_good_good_good
ext_web_failed_loads{perf}=47_22_31_40_31_41_41_44
ext_web_successful_loads{perf}=28_33_31_30_31_29_29_29

where ext_<cycle>_failed_loads represent failed attempts to load the URL in time allotted for each of the test loops.  For example,

  ext_audio_failed_loads{perf}=29_71_0_71_4_71_71_37

29 is failed loads of an audio URL in the first loop, 71 in second loop and so on.

ext_<task>_successful_loads tracks when URL loads succeed before the timeout.

Possible ways to improve this data,

1. Add ext_<task>_desired_loads{perf}.  While seasoned testers know the desired loads (36 for task=web, 6 for task=doc, etc) would be good to publish probably
2. Output to log or keyval specific URL failure and timestamp.  the _failed_ keyval is an aggregate which when non-zero does indicate test unhealthiness but without any specifics.  For example for web task loop1 there are 47 failed, 28 successful.  With desired @ 36 we could speculate 47 / (36 - 28) =~ 5 attempts to load each of those failed URLs occurred over the 60secs allotted but knowing details of URL & timestamp would make that clear.
3. Add network health/data keyvals or logging.  If facilities exist to track the resulting payload size on success or the specific HTTP status error on failure that would be useful.  Additionally a keyval(s) aggregating the transmit & receive size and/or D0 (running) vs non-D0 (idle) status of the network connection could provide visibility into network power.