this post was submitted on 19 Aug 2023
23 points (100.0% liked)

Selfhosted

40401 readers
823 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Hi people!

I am in the process of setting up my selfhosted services and I would like to have a status monitor for them and for my websites. I really like Uptime Kuma, but right now I am not sure where should I host it. I do not want it on my VPS (for obvious reasons) and I do not have a spare old PC that I would run at home. At first I wanted to have it on a separate, very small VPS from my server provider but in different datacentre, but without a public IPv4 (only v6 are free) I’m not sure how I would expose it to the public (any tips?).

I would want to ask you for some recommendations for sites offering a hosting option for just this one thing, preferrably with a free tier(?). The docker container takes up only about 120-130MiB of RAM so even 1vCPU, 256MiB of RAM and a few hundred MiBs of storage would suffice. I don’t mind something with “sleep after a period of inactivity” type of thing, as I can just setup a cron job to ping the site. Or if you have some other way to have a FOSS status monitor hosted outside of my prod. server, I will appreciate every tip.

Thank you very much, hope you are having a good day :)

you are viewing a single comment's thread
view the rest of the comments
[–] PriorProject 7 points 1 year ago (1 children)

This isn't exactly an answer to your question, but an alternative monitoring architecture that elides this problem entirely is to run netdata on each server you run.

  • It appears to collect WAY more useful data than uptime Kuma, and requires basically no config. It also collects data on docker containers running on the server so you automatically get per-service metrics as well.
  • Health probes for several protocols including ping and http can be custom-defined in config-files if you want that.
  • There's no cross server config or discovery required, it just collects data from the system it's running on (though health probes can hit remote systems if you wish).
  • If any individual or collection of services is down, I see it immediately in their metrics.
  • If the server itself is down, it's obvious and I don't need a monitoring system to show a red streak for me to know. I've never wasted more than minute differentiating between a broken service and a broken server.

This approach needs no external monitoring hosts. It's not as elegant as a remote monitoring host that shows everything from a third-party perspective, but that also has the benefit of not false-positiving because the monitoring host went down or lost its network path to the monitored host... Netdata can always see what's happening because it's right there when it happens.

[–] SniffBark 9 points 1 year ago (1 children)

I run netdata to collect usage statistics etc. directly on my VPS. I don’t need Uptime Kuma for that, because of course I know right away if my server is down or if it’s just a service. I am hosting some things also for my friends and family, and I’d like to have an option for them to check what is going on. Imagine they cannot access a service, they go to the status page and see that it is either a planned maintenance (updating, editing the configuration etc.) or there something else wrong, and they will see exactly when the service went back online. Without externally hosted status page like this, all they would get is an error. This way is much nicer for the non-technical audience.

[–] PriorProject 4 points 1 year ago

Fair enough, sound like you have a well considered use case for Kuma specifically. Good luck, I don't have much to offer on your OP question.