Realised that missed attestation alerts via beaconchain are less useful when running DVTs so I created a simple client-level downtime alerts Telegram chatbot for myself.

Any solo stakers keen on a fun weekend project to share some feedback? -

Realised that missed attestation alerts via beaconchain are less useful when running DVTs so I created a simple client-level downtime alerts Telegram chatbot for myself.

Any solo stakers keen on a fun weekend project to share some feedback? - https://github.com/samuelclk/ETH-node-alerts-TG-bot

Missed attestation alerts via the http://beaconcha.in watchlist occur on the onchain validator key level. 

However, using DVTs means that your node =/= validator. 

i.e. A cluster of X nodes is responsible for hosting Y validator keys.

Cultivating the ETH solo staker talent pool in SEA @ Stakesaurus.

Try our DIY guide yourself here - https://linktr.ee/stakesaurus

As a solo staker using DVTs, I needed a way of being notified when my DVT-enabled node goes offline on the device/server level instead of on the onchain level.  

The http://beaconcha.in app does have a “machine offline” notifier but only for 1 machine on the free plan.

I wanted something that puts all DVT operators of a cluster in the same group chat and alerts everyone when any one of the nodes in the cluster goes down — keeping everyone accountable!

This lightweight Python script can be run externally on a small + low-powered device and scheduled as a CronJob to monitor as many nodes as you want. 
 
Running it externally (vs from your node) means that the risks/trust assumptions from running unknown scripts are much lower

The condition, however, is that the nodes you want to monitor this way need to be in the same VPN (e.g. Tailscale), which means it’s possible for a malicious cluster participant to DOS the other nodes by overwhelming them with pings. Although there are no benefits to doing so.

So how does this tool work?  

In 4 simple steps,

1) The script starts by making HTTP GET requests to the specified IP address and port. 

e.g. http://<external_IP>:9000. These requests are essentially asking the server, "Are you there?”

2) Next, for the script to consider the consensus or execution client to be "up," the service at the IP address and port must respond to the HTTP request. 

i.e. the client's API or health check endpoint responding with an HTTP status code of 200 OK

3) The script also includes a timeout (e.g. 5 seconds), ensuring that if the client doesn't respond within a reasonable timeframe, it's considered "down." 

This helps differentiate between an unresponsive service and one that's simply slow to reply.

4) Finally, it sends a message to the chat groups designated for each endpoint that was checked if it is “down” or “cannot be reached”. \

This completes the downtime alerts flow.

Disclaimer: This is meant to be a fun project for solo stakers and is in no way meant to replace professional monitoring tools used by institutions. 

It's a lightweight solution ideal for scenarios where detailed metrics are not required.

Give it a try and let me know what you guys think!

This means that we either need to manually check on our nodes periodically (tedious) or act when the cluster fails to achieve consensus, leading to missed attestations (and free-rider problems).