The controller currently uses the timeout configured in the op element for the recurring monitor (or the default if none) when sending the initial recurring monitor to the executor. The executor uses pcmk_monitor_timeout, and if that's longer than what the controller is using, the controller can consider it timed out too early, before the executor replies.
This would be a good time to update the documentation of fencing timeouts along the lines of CLPR#2107.
See also: