Best Practices for Implementing a Heartbeat Feature in a Laravel App to Track Offline Status

Question

I'm trying to implement a heartbeat feature for offline tracking that just sends an offline message to the server once the web browser app (Laravel-based) is offline. Ideally it will ping the app's URL every x seconds and then push an offline message to the remote MySQL database if the response fails.

The question I have in mind is:

• Should I use the pinging logic from client-side or there's a way to do it server-side.

• Philip Kendall: What exactly do you mean by an "offline message"? You clearly can't send a message from the client app if the client app is offline, that's the definition of "offline".
• meowyn0316: What I meant is that the client will send a heartbeat signal to the server every X seconds. The server listens for this signal, and if it doesn't receive a response within the set interval, it marks the app as "offline." Once the signal is re-established, the server updates the app’s status to "online."

Answer 1

You should start by assessing the risks. What exactly you need to check? What "offline" exactly means? Why do you need a heartbeat? What would happen if the heartbeat don't do its job? Depending on those specifics, the solutions could end up being very different.

Example 1

You are using an old, idiosyncratic deployment tool, mandated by your company, which occasionally fails the deployment on one of the nodes of a cluster, but has no mechanism of informing you about the failure. When it fails, production is still up, as other nodes are here to handle the requests. You want, however, to be proactive and to run the deployment again as soon as it fails.

Here, you can have several solutions:

• A simple process, ran directly on every node, which would check if the service is available or not, and send a notification when the service goes down, and another one when it's up. Or, if the deployment is expected to bring the service down for a short amount of time, the process could wait for that time before notifying you.

• A monitoring panel that would ping the service directly at the level of individual nodes, showing the ones that are red (and possibly showing for how long the service was down).

Example 2

You're hosting a small website on your home computer. Your ISP cannot be trusted to provide a permanent, good quality, internet connection. You want to know when your website is down for your visitors, just by curiosity.

Here, you need the monitoring process to run outside the PC that is running your website. Actually, you even want it to be outside of the domain of your ISP. Maybe even in a different country, although this is not mandatory. You may either use one of the numerous online services for that, you draft your own, hosted, say, in the cloud, that would check your website periodically and send you a message when it cannot be reached.

Monitor your monitoring

In any case, by introducing a process that monitors your services, you should also need to monitor the process itself. After all, it is not only useless, but actively harmful to have a monitoring process that could possibly be down for months—it gives you a wrong sense of security.

If you're going to set up monitoring, think about the way you would monitor it. Bringing services down and checking that the monitoring reacted to that is one of the ways to do it. For instance, for my own servers, I'm relying on a monthly drill where I cut the power, and check that (1) the UPS works as expected, (2) the monitoring panel shows that there is an outage, and (3) within seconds, I get an alert on my phone.

More automated and more elaborate strategies may also exist. For instance, an automated test may run regularly to check what happens if it messes up with the network, or with the firewall, or with the reverse proxy, checking that the monitoring systems reacted as expected.

Naturally, if you rely on such automated tests, you also should ensure they work as expected. Monitor the thing that monitors the monitoring of your systems. You get the idea.

• meowyn0316: Cant upvote yet but thank you. It wasnt in my mind to monitor the monitoring process. 😆
• Arseni Mourzenko: @meowyn0316: now you can. Congratulations with your first rep points.

Answer 2

• Server-side checks will not detect connectivity issues. Modern deployments are so complex, that external connectivity misconfiguration is commonplace.
• Client-side checks are hard to do, due to authorization issues.

I suggest to use a dedicated off-site verifier or rely on a third-party.

• meowyn0316: I see. I'll be searching possible 3rd party providers for this just in case.

Answer 3

HTTP/1.1, HTTP/2, and HTTP/3 all support full-duplex streaming.

What the above means for the present question is that a single request can be kept alive, in theory, indefinitely, so the client can connect once, and the "heartbeat" idea can be substituted for the client disconnecting, otherwise the client will maintain a connection to the server until the connection is closed by the client or server.