status.ntppool.org reports it is up, but I get a 504 Gateway Time-out.
It’s been like that for more than a day I think
Whoops – no, for about 21 hours! I’ll have it fixed in the next ~15 minutes.
It should be resolved now; thank you for the note.
I’d made a small change to the logging that was insufficiently tested, ugh. (In retrospect it was erroring out loud and clear, but I missed it in the logs).
I noticed the same. Would it make sense and be possible to update the status monitoring system to also reflect such incidents? I.e., if some core piece of the service isn’t working, it probably should not be shown as up on the status page. Or maybe the particular component that was down this time currently simply isn’t a service that is monitored by the status page yet?
The status page doesn’t have any automatic monitoring actually! It’s run by statuspage.io and they have an API, but I’d need to find or write some automation to take prometheus metrics / alerts and push them to appropriate status updates.
Is the login system sending verification emails? I’m currently trying to add a server.
Hmm, that is indeed something that would need to warrant the effort to do this, so that is not what I meant to suggest.
Rather, I was surprised that the service returned a blatant “504 Gateway time-out”, but still, the status page considered the service as being fine.
I don’t know the details about how the statuspage.io service works, but I’d hope there would be a way in their API to catch such errors without needing to custom code capturing and pushing of prometheus metrics to detect such blatant issues.
Welcome to the forum, @9pfs!
Not that I am aware of. Maybe in case of forgotten/lost passwords, a reminder e-mail could be triggered. But I have not yet come into that situation.
Verification of servers does not involve verification e-mails. Rather, on the management page with your servers, there will be a link next to a server’s entry that will give you further instructions. Those involve calling a specific HTTP(S) URL from the server to be verified, or from another system in its network vicinity (same subnet, with applicable accepted subnet size specific to the IP version).