For those using a self-hosted Alby Hub that hosts their Lightning Network Wallet to send/receive sats on the Nostr network, it is crucial that the connected wallet stays online. If not, the user cannot make or receive any sats.
I’ve noticed twice already that my wallet was offline, only about a day later. It seems that whenever my server has been rebooted, or the Alby Hub container is restarted after an update, that the Alby Hub requires a login again just to reactivate the wallet connection. All you have to do is go to the URL for your Alby Hub and type in that password, then everything is active again.
My problem though was, I was using my own self-hosted Uptime Kuma to alert me if my Alby Hub was offline. But if the container was restarted the Alby Hub page showed as online, and this alert only worked if the whole server was down or the container did not restart. It did nothing for Alby Hub being online, but not logged in.
I did determine earlier on that the indicator that showed if the Alby Hub wallet was online and logged in, would change the balance attribute to show either the sats balance as a number (logged in), or it changed the balance value to null if it was not logged in. If you have activated your access token on the Get Alby site at https://getalby.com/developer/access_tokens/new for balance:read, you can easliy run the following command from the terminal to read that data: curl https://api.getalby.com/balance -H "Authorization: Bearer access_code" where you replace access_code with your own access code. This will return some JSON code, and you will see a value for balance that either shows your actual sats balance, or it will show null.
So my multi-hour challenge today was to try to get Uptime Kuma to read that balance and if it was a value above 0 then consider the wallet online, but if it showed a null value, then send an alert to say it is offline.
My struggle was to get the returned value correctly evaluated in Uptime Kuma’s rather simplistic JSON evaluation field. The null value was also throwing out issues as you can’t use the number() function to convert a null value (it gave an error) and this was obscuring the logic I was trying to test.
In the end, the parts of it that worked in Uptime Kuma were (see post’s featured image):
- Monitor Type:
HTTP(s) - Json Query - URL:
https://api.getalby.com/balance - HTTP Method:
GET - HTTP Body Encoding:
JSON - HTTP Body:
{"balance": "application/json"} —this gets the value of balance - HTTP Headers:
{"Authorization": "Bearer access_code"}– this is used to authorise access to query the balance value - Json query:
balance != null ? 1 : 0 —checks if balance is not null, and if not then return 1, but if balance is null then return 0 - Expected value:
1 —balance is expected to be 1 if all is fine
The crucial parts are the test statement in the JSON query field compared to the Expected value field. If the query matches 1 then all is fine and there is no alert, but if the query changes to 0 then an alert is triggered.