I am getting 14421 error messages and ended up reading the following KB
Here is the part I'm referring to :
Problems either with the Backup job or Copy job are most likely to result in "out of sync" alert messages. If "out of sync" alert messages are raised and if there are no problems with the Backup or the Restore job, check the Copy job for potential problems. Additionally, network connectivity may cause the Copy job to fail.
Even though no monitor server is in use I think this is what's happening :
exec sys.sp_check_log_shipping_monitor_alertprocedure relies on. This update is sent from the standby to the production and fails to connect somehow.
This server was migrated before and probably has configuration issues as there are only 25 out of 93 databases on this server using log shipping. Yet, all 93 come out from the return of this procedure telling me they are 175 000 minutes late.
On the standby the view is working normally, should I expect the "last restored date" to be updated on the primary server too or is this not a thing ?
Use this command:
@agent_id = @agent_type =
Arguments [ @agent_id = ] 'agent_id' The primary ID for backup or the secondary ID for copy or restore. agent_id is uniqueidentifier and cannot be NULL.
[ @agent_type = ] 'agent_type' The type of log shipping job.
0 = Backup. 1 = Copy. 2 = Restore.
agent_type is tinyint and cannot be NULL.
[ @database = ] 'database' The primary or secondary database used by logging by backup or restore agents.
[ @mode ] n Specifies whether to refresh the monitor data or clean it. The data type of m is tinyint, and the supported values are:
1 = refresh (This is the default value.) 2 = delete