u/According_Menu_1732

probara uptime

yeah as others already mentioned, Uptime Kuma / UptimeRobot / healthchecks.io can all do the basic push heartbeat thing

tbh if thats literally all you need, Kuma push mode is probably enough

but if you want something self hosted that can grow beyond just heartbeats, im building Probara

for your camera sites you can use a push heartbeat, so nothing needs to be publicly accessible. just have the Windows task scheduler or a linux cron hit the Probara endpoint every X minutes, and if the heartbeat stops it goes down + alerts you

no agent needed for that part. theres also a host agent if later you want actual machine cpu/memory/disk telemetry

the main difference is Probara is built more like a distributed monitoring platform, workers are seperate from the control plane so you can add multiple workers/locations as you grow, and use quorum for checks where you want confirmation from more than one location

so probably overkill for just 1 heartbeat 😅 but could make sense if you're managing a bunch of camera systems / servers

docs: https://probara-uptime.com/
repo: https://github.com/yassinebenameur/probara

if you're ok with self hosting, this is pretty much the reason I started building Probara

for 1min or even 30s checks, SaaS pricing starts adding up really fast because you're basically paying for their compute. With Probara you run the infra yourself so you're not tied to those free tier limits

also its not just one process doing everything, checks are handled by separate workers so if you start monitoring more stuff you can add more workers and even run them from different locations

you can also use quorum between locations which is nice for avoiding false alerts when one region/network is having issues

still early but its open source

docs: https://probara-uptime.com/
repo: https://github.com/yassinebenameur/probara

if you're ok with self hosting, I’m building Probara and it might fit what you're looking for

its free/open source so you dont have to worry about a free SaaS tier suddenly changing the rules for client/commercial sites

for a few client sites you can just run it normally, but it was also designed to scale if you add more later. checks are handled by separate workers so you can run multiple workers / locations, and even use quorum so you dont alert a client just because one monitoring location had a network issue

also has status pages, alerts and http tcp dns tls monitoring etc

docs are here if you wanna have a look
https://probara-uptime.com/

repo: https://github.com/yassinebenameur/probara

yeah this is exactly one of the things that gets a bit limiting with Uptime Kuma imo

once you want to reuse monitors somewhere else, move them to a fresh instance or manage multiple Kuma servers, theres no really clean portable monitor config workflow

its one of the reasons I started building Probara differently, monitors are managed centrally and the actual checks are done by separate workers, so you can add workers / locations without having to clone and maintain multiple full monitoring instances

might be interesting for what you're trying to do

docs: https://probara-uptime.com/
repo: https://github.com/yassinebenameur/probara

have a look at probara
http://probara-uptime.com/

github
https://github.com/yassinebenameur/probara

yeah for your project I think this would be a really nice direction

instead of just connecting 2 uptime kuma instances, having multiple workers/probes doing the checks and then a quorum on top would solve the routing issue and also scale much better as the number of checks grows

thats actually how I approached it in Probara, the workers are separated from the main app so you can just add more of them / put them in different locations

might give you some ideas if you start working on this
https://github.com/yassinebenameur/probara

Fair question. I actually looked at contributing to existing tools first, but most of them were built with pretty different architectural assumptions.

The things I wanted — distributed workers, private probes, multi-location quorum, mesh monitoring ... would have meant changing quite a lot at the core, not just adding a few features. So I figured it made more sense to start fresh, and not push an existing project in a direction its community might not even want.

checkout probara ( i'm the author)
https://probara-uptime.com/
designed it to solve this exact problem, feel free to collab

checkout probara (author here)
https://probara-uptime.com/

Project Name: Probara

Repo Link:
https://github.com/yassinebenameur/probara

Doc Link:

https://probara-uptime.com/

Description:
Probara started because I was using Uptime Kuma and eventually outgrew the way I was using it.

I still like Kuma a lot. It has a great UI, it’s easy to deploy, and it worked well for me for a long time.

The problem came when my monitor count grew and I wanted to treat monitoring more like the rest of my infrastructure.

I wanted Kubernetes deployment, horizontal scaling, independently scalable workers, and easier management of large monitor lists. I also had a bad upgrade where a database migration ran for days before eventually failing, which pushed me to look more seriously at alternatives.

I tried other approaches too, including Prometheus + Blackbox Exporter and more complete platforms like OneUptime and Zabbix.

I kept ending up between two extremes: tools that were simple and pleasant but limiting for what I wanted, or platforms that were very capable but much more complex than I needed.

So I started building Probara.

The core idea was to split the platform into separate services for the API, scheduler, workers, alerting and status pages. The workers execute the checks, so the check layer can scale independently as the workload grows.

Most of the backend is Go, with NATS JetStream and PostgreSQL, and the UI is Next.js.

While building it, I became especially interested in multi-location monitoring.

You can run workers in different clusters, regions, offices, homelabs or private networks and check the same service from several places.

There is a configurable failure quorum, so one broken monitoring location does not automatically mean the service is down, and there is also a connectivity mesh between locations to help distinguish a service outage from a network-path problem.

Over time I also added things I usually want once a tool becomes part of a real environment: OIDC/SSO, RBAC, service dependencies, incidents, maintenance windows, API keys, audit logs and customizable status pages.

It currently supports HTTP, TCP, DNS, ping, TLS, WebSocket, gRPC, SIP, databases, browser/API checks, heartbeats and host monitoring.

I’m not trying to replace Prometheus/Grafana. I see Probara more as the blackbox/synthetic side of monitoring: actively checking whether something works, and from where.

The project is still young, and I’m mainly looking for feedback on the architecture, scaling model and multi-location/quorum approach.

Deployment:
Kubernetes via the included Helm chart, with independently scalable components.

Docker Compose is also available.

Documentation for installation and architecture is in the repo.

AI Involvement:
AI was used throughout the entire development process.

https://preview.redd.it/lxdn6wetnqih1.png?width=1440&format=png&auto=webp&s=fd033c4857da800f5bdea2a53a2224b176dee441

I still make the final decisions, review changes, test the system and operate it myself.

License: AGPL-3.0

i’m low ping player , 5 - 20 ms