If you ssh to the ap, you could verify it has the backup controller ip, and you could verify you can ping the backup controller from the ap.
# cget config | grep -i failover
failover bmIp [1] 192.168.2.44
failover bmIp [2] 192.168.2.45
#
# ping 192.168.2.45
PING 192.168.2.45 (192.168.2.45): 56 data bytes
64 bytes from 192.168.2.45: seq=0 ttl=63 time=1.2 ms
64 bytes from 192.168.2.45: seq=1 ttl=63 time=0.9 ms
--- 192.168.2.45 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.9/1.0/1.2 ms
#
Also make sure the data port on the failover secondary controller has the "Ap Registration" checkbox checked under vns-toplogy->data port ( otherwise aps would not be able to connect )
If everything checks out, then either the ap either had a real network issue preventing it from reaching both primary and secondary controllers, and perhaps more, or it had an internal issue preventing causing a network connectivity issue until it timed out and rebooted.
If you suspect internal issue, you can open a ticket with GTAC to investigate further.