Logfile on the standby contains:
2018-02-01 22:08:34 UTC [21083]: [4-1] db=,user= LOG: consistent recovery state reached at 5ED82/6F1691F0
2018-02-01 22:08:34 UTC [21083]: [5-1] db=,user= LOG: invalid contrecord length 4711 at 5ED82/6F1691F0
The first line indicates that the standby has resumed replication successfully. Note that the second line is an information "LOG" level notice. Even though it is reporting "invalid contrecord length", that is simply an indication of where the standby had reached the last complete WAL file locally before resuming replication from the upstream node. This is normal behavior from a standby when resuming replication with an upstream node that has stopped unexpectedly.
You can check pg_stat_replication for send_lag and apply_lag (results displayed in bytes) to confirm the standby has attached to the primary and is replicating as normal.
PostgreSQL 10 and later:
SELECT
pg_wal_lsn_diff(pg_current_wal_insert_lsn(), sent_lsn) as send_lag,
pg_wal_lsn_diff(pg_current_wal_insert_lsn(), replay_lsn) as apply_lag
FROM
pg_stat_replication;
PostgreSQL 9.6 and earlier:
SELECT
pg_xlog_location_diff(pg_current_xlog_insert_location(), sent_location) as send_lag,
pg_xlog_location_diff(pg_current_xlog_insert_location(), replay_location) as apply_lag
FROM
pg_stat_replication;
standby node wasn't able to connect to master, because master was down through to hardware error.