Your comment on a reverse ssh tunnel "stalling" after a while is probably due to a NAT router trying too minimize its open connections table and should be resolved by using the "ServerAliveInterval" directive as explained in the OpenSSH FAQ.
In some cases the router/firewall is aggressively pruning you sessions anyway (bad!) when the link is left idle for a long time which forces you to lower the ServerAliveInterval (cf. note).
The trick in this case is to use a sort of wrapper monitoring the ssh daemon and restarting it when necessary, autossh does exactly that, that should solve your problem right away !
note : This is something you want to limit because increasing the frequency of keepalive packets on an unstable link raises the risk of disconnections; which are defined as x keepalive response packets, in reality TCP ACK packets, failed successively.
If your link is reliable feel free to lower that directive to your convenience (be wise, you don't need a keepalive packet per second) to detect more quickly disconnections from the server.
PS: To explain my comment on the question, I'm a bit repulsed by the ideas of using ping as a condition to restart a service and using it on a server you don't own and thus can't guarantee the availability, maybe tomorrow google will decide to stop responding to echo pings and your server will keep rebooting indefinitely.
Another problem is what you define as "internet connection" is by definition a big collection of networks and testing a single end point may be too small to get an idea of your connectivity on the network, that's why monitoring services on the web uses a variety of links to track responses time/uptime/etc...