Mostly people will ping a firewall or server to see if it’s up. However, if it goes down, and you aren’t onsite, who knows why it’s down? It could be a problem with the server, a denial of service attack, someone is using all the bandwidth so now it’s not responding to pings, internet is down, etc. To rule out internet issues on the internet service provider’s end (comcast,verizon,etc.) a traceroute can be run to the ip address of the device being monitored. Assuming a firewall is the first device that the internet reaches on the remote network, the last hop before the firewall should be monitored via ping as well. If there is an internet access issue and access to the firewall is lost but access to the last hop is also lost, then it’s a problem with the ISP and you don’t have to troubleshoot your own equipment. So a lot of time is saved right there with that additional monitoring and it only takes about a minute to set up on typical ping monitoring tools provided you already have the monitoring software running and otherwise configured.
It should be noted that the last hop is not guaranteed to be the same ip address indefinitely. However, they change rarely. In my experience, maybe once every couple of years, or even longer than that. Regardless, a monitoring tool has the ability to notify via email or other methods as to the status of a device being monitored, so a notification could be sent in the instance that the last hop ip is no longer responsive. A minor inconvenience for the ability to instantly know if an access issue over the internet is (and sometimes more important was) an ISP’s problem or not. It can prevent a lot of time being wasted going onsite or waiting for an ISP to respond. If someone wants to know why they lost access a few days ago you may be able to look at the logs and check the last hop and say ‘here’s proof as to the ISP being responsible.
There is also the consideration that if the ISP’s equipment is not functioning properly, it may not necessarily be their fault if there’s a natural disaster or prolonged power outage.
Additionally, the problem still could be before the firewall even if the last hop has not dropped when the firewall did. For example, between the last hop and the firewall someone hits a telephone pole with their car and takes down the line. The last hop will still be up, but the firewall will no longer be able to get out to the internet. So monitoring the last hop is only useful when both it and the firewall goes down, indicating a definite problem outside of the building, outside of your responsibility, unless you are the internet service provider.