Postgresql replication slot used by barman has a long replay_lag
This large replay lag in pg_stat_replication seems to belong to a pg_receivewal process. Now pg_receivewal writes a copy of the WAL files, but it does not apply them anywhere. Consequently, it will not report back to the primary server that WAL was applied.

This is perfectly normal; compare commit fd7d387e05.

The &ldquo;Failures of WAL archiver&rdquo; are also nothing you have to worry about. This number probably comes from pg_stat_archiver and indicates that there has been a problem archiving WALs in the past. This problem must have been resolved, because &ldquo;Last archived WAL&rdquo; indicates that more recent WAL files have been archived successfully.

PostgreSQL won't skip archiving WALs &mdash; if archiving fails, the archiver gets stuck at that place and retries until successful.