Monitoring alerted me to a couple of servers which had lost the ability to replicate SYSVOL using FRS. Microsft KB290762 (https://support.microsoft.com/en-us/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-service) provided instructions on how to recover.

In summary, on all members of the replication set (in this instance all DCs) stop the ntfrs service using:

net stop ntfrs

The choose one server which will be the authoritative copy and set BurFlags to 0xd4:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 0xd4 /f

On the other servers, set BurFlags to 0xd2:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 0xd2 /f

On the authoritative server, start the ntfrs service and watch for event 13516 in the “File Replication Service” event log. Once that event is logged, start the ntfrs service on the next server and again wait for the 13516 event log. Repeat this on the remaining servers.

EDIT: I have since discovered FRS was being used due to upgrades from Windows 2003. Followed https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process/ to migrate from FRS to DFSR. In future, if replication breaks it can be reinitialised by following this doc: https://support.microsoft.com/en-ie/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-for-dfsr-replicated-sysvol-like-d4-d2-for-frs