Out of sync on a secondary is the availability group telling you the log stopped flowing or applying there, and the diagnosis names which, then the recovery follows the cause rather than a blanket reseed:

See the real state first: the AlwaysOn dashboard in SSMS, right click the availability group, Show Dashboard, shows each replica's synchronization state and health, and the columns that matter are the synchronization state, the log send queue and the redo queue. A large log send queue means the primary cannot ship log to the secondary, a network or connectivity problem, while a large redo queue means log arrives but the secondary applies it slowly, a secondary performance problem. The distinction points the fix.

The common causes by what the dashboard shows: connectivity issues between replicas, the endpoint or network dropping, stopping log flow, checked with the same endpoint and firewall reasoning as mirroring since AGs use database mirroring endpoints underneath. A disk full on the secondary stopping log application. The secondary suspended, manually or by an error, showing as not synchronizing and resumed with ALTER DATABASE db SET HADR RESUME. And a log growth event on the primary, a large transaction or index rebuild, flooding the send queue faster than the link carries, a transient that catches up once the burst passes.

The recovery by cause: a suspended database resumes with HADR RESUME and catches up if the log chain is intact. A connectivity problem fixed at the network restores flow and the secondary catches up automatically from where it left off, since the AG resumes from the log. A secondary that fell too far behind, the log needed to catch it no longer retained on the primary, needs reseeding, either automatic seeding on modern versions or a manual restore of a fresh backup to the secondary and rejoining, the heavier recovery reserved for when catching up is genuinely impossible.

The order that avoids overreaction: diagnose from the dashboard what actually stopped, resume a merely suspended replica, fix connectivity or disk if those are the cause and let it catch up and only reseed when the gap is truly unbridgeable, since reseeding a large database is hours of work that a simple resume or network fix often makes unnecessary. The out of sync alarm is usually a resumable pause rather than a rebuild.