Show HN: Peeng – like Pingdom, but the other way around and simpler (peeng.sh)

84 points by talboren ↗ HN
Hey folks! Shahar and Tal from Keep (https://www.keephq.dev) here!

For the last few weeks we’ve been building Peeng and can now share our beta with you: https://www.peeng.sh. Peeng is the easiest and quickest “heartbeat” architecture we could think of. Just pick a subdomain (e.g. x.peeng.sh), configure an interval, an endpoint, and a payload, and hit that subdomain every <X (interval) seconds — If you won’t, Peeng will send an HTTP POST request to your configured endpoint.

It’s Pingdom/Cronitor/heartbeat.sh free alternative (but the other way around and A LOT simpler, with a lot more capabilities), suitable for developers, system administrators, DevOps, and individuals with complex networking situations (think “onprem” or K8s clusters with no inbound). Instead of inbound heartbeat checks — Peeng presents outbound heartbeat checks!

Quick demo: https://youtu.be/ZX5mrnMRCwU

Why we built this:

- We needed an easy way to let Keep (https://github.com/keephq/keep) customers behind closed networks monitor their Keep instance - We needed an easy & quick way to setup monitoring for our cronjobs - We wanted to give people with complex networking situations (e.g. behind a firewall) an easy way to monitor their services/processes

The beta version lets you:

- Create 5 endpoints for free - Configure the endpoint and the payload to be sent when the subdomain is not hit - See the visits (every HTTP GET request to your subdomain) and requests (every HTTP POST sent to your configured endpoint) - Secret header (x-peeng-secret) that confirms requests are made by you

What’s next:

- A status page that displays your subdomains and their health together with embeddable status blocks that allow you to display the status of an endpoint in your web page (you can also send query params when sending the GET requests that will be included) - Rest API (for subdomain creation, beats retrieval, etc., imagine curl -X POST peeng.sh/subdomain -H API_KEY —json {”subdomain”: “hn”, “endpoint”: “https://xn--ivg, “payload”: {…}}) - Hierarchy-based subdomains that allow you to create a nested heartbeat solution (i.e. dynamically create a heartbeat subdomain under x.peeng.sh → y.x.peeng.sh, z.x.peeng.sh)

This is still very early, so we’d love to hear your feedback and opinions. We’re open to any feature request, so just reach out via Intercom :)

78 comments

[ 0.32 ms ] story [ 152 ms ] thread
I understand if the full app experience doesn’t work on mobile, but at least consider allowing mobile visitors to view the landing page. I’d love to check it out, but am on mobile and get a full screen “not supported” banner.

Edit: or maybe redirect mobile visitors from peeng.sh to your .dev site.

Hey! I've just removed the restriction on "/" for mobiles, can you refresh? (maybe incognito until cache is refreshed or something)
FYI: Menu button doesn’t work for me on iOS.
Those are the compatibility issues we had and the reason we decided to put a mobile redirect on -- working to fix this ASAP!
A service in a very similar vein is https://healthchecks.io/ - which also provides a nice perspective on how low-effort the setup for a service with a substantial amount of users can be. https://news.ycombinator.com/item?id=31488910

The blog also contains a bunch of useful information and guides around the topic, including various unusual configurations (arduino/esp8266) as well as information on self-hosting.

I've used healthchecks.io for years (and Laravel eco system has some heartbeat checks built into their system), I'm curious how Peeng differs?
Peeng (which is now gnip.io, ping in reverse) is now only for cron/onprem monitoring but eventually we want to add it a lot of other features (nested subdomains, dynamic status pages, pings (not reverse)).

If you have any idea what would be make Peeng even more great it'll be cool to hear!

(comment deleted)
Congratulations on shipping!

It's not really clear how this is different to heartbeat monitoring, is it because it uses a subdomain instead of a URL path?

There are plenty of tools that does heartbeat monitoring. We focused on being - free, fast, and simplest UX possible.

The next things we gonna ship are going to be different though - we are going to add status page + nested subdomains so you'll have x.y.peeng.sh so all devices that reports to x.y.peeng.sh will be aggregated to y.peeng.sh status page.

I don’t currently need something like this, but I like the simplicity and it seems handy.

Tech aside, I’m compelled to say that I don’t like the name. It is one letter off from a bodily function, and the pronunciation is even closer.

Edit: the menu button on the landing page doesn’t work for me on iOS.

Yep, got that feedback a couple of times -- we'll do something about it, we plan on supporting more domains anyhow.

Thank you for the feedback!

seconded; calling it "pee-ng" will limit adoption
we are open to suggestions
piing (unless it’s taken)
more of the same, isn’t it?
yeah maybe. Slightly less like pee and more like ping?

naming is hard…

syng ? syn + ping

Neat! I definitely read the name as "Peeing" and was confused. (Most people parse words using the first few letters and last few letters when they scan.)

The blurb on the site was difficult for me to parse, mentally. It's wordy and awkward with the negative in there:

> Receive an HTTP request whenever your heartbeat endpoint is not pinged for a configured interval of your choice.

"Get POSTed when your endpoint stops receiving a ping." is where I got to after reading your description here, but it's sorta unclear what "your endpoint" means (it's ambiguous, is it my site's endpoint? or my "peeng endpoint"?)

It's your configured endpoint that gets POSTed when your Peeng subdomain stops receiving pings.

Anyway, gotcha, we'll do some work on the text there! Thank you!

(comment deleted)
Now I can't unsee "peeing"
The next generation of pee: PeeNG
I been looking for a reverse of pingdom and this post has caught my eye but not sure if it does what I need.

I'm looking specifically for a ping/heartbeat service to observe our long-running process scripts, where I will make an HTTP request to it every x interval so I know that the background script is still alive.

Does anyone know of which?

Hey jaequery, Peeng is the solution for you! happy to further help you set it up, join our Slack at https://slack.keephq.dev and I'll shoot you a message
the name suffix suggests that it is implemented as a shell script.

the homepage does not convey any information about this script or anything else like setup instructions.

if i click on the github links in the top row i see a codebase that is supposedly for the server side.

i would like to know more but you're not making it easy.

we liked the .sh domain but perhaps it wasn't the best choice. signing in and creating a subdomain gives a full list of examples: https://snipboard.io/l2TU1c.jpg

let me know if I can help anyhow

re the GitHub repo: it's just a reference to our OSS project "Keep", not the BE of Peeng. sry for the confusion
(comment deleted)
I'd suggest your homepage mention a few use cases (like the ones you described above). My first thought when I clicked the link was "What would I ever use this for?".
Thanks @jedberg. I’ll add a few examples to the front page.
So you are basically making a dead man's switch, it seems [0]. However, why should I send requests to you rather than you pinging me? It saves on your server costs, sure, but it can be more of a hassle for me as the developer when I just want to know if my service is up.

And definitely change your name, the first thing I though of was pee or peeing, not a good connection to have in people's minds.

[0] https://en.wikipedia.org/wiki/Dead_man%27s_switch

There's a great service already existing with a riff on that name, even - https://deadmanssnitch.com/

DMS is useful for stuff like crons where you're trying to monitor an event that happened rather than whether a service is online. No way to ping a cronjob from the outside world, but the cron can report that it ran successfully

Wouldn’t this allow for health checking services that don’t have public endpoints? My first thought was an alert to me that my home internet (or server) is down.

Granted I’d probably just set up a server to do that unless this was insanely cheap.

because that’s how pingdom works, and why recreate exactly what they do?

This makes it easy for internal services that maybe you don’t want to setup a publicly accessible health check ingress, would be my guess.

Sounds like https://deadmanssnitch.com with a bigger free plan, or is there a fundamental difference?
This is the MVP which is not much different except a better UX (we hope). The next version gonna have lot of other things such as nested subdomains and status page per endpoint/subdomain.
I like your product but your pricing per endpoint is not what I would choose:

10 endpoints - $1 per endpoint per month

20 endpoints - $1.5 per endpoint per month

30 endpoints - $1.33 per endpoint per month

Nice catch, we are going to change that!
How does Peeng differentiate between 'pings' from different services coming from the same IP? Payload? For example, if I wanted to use this for an appserver and db server and both have a NAT gw as the source, would I need to separate Peeng domains or can Peeng operate on the payload?
(comment deleted)
You can send query params when hitting your subdomain. We keep those query params and can then display them to differentiate between requests (coming from a NAT gw) —- does that help?
This seems like a neat little service.

Just a heads up. Here in the UK Peng is slang for sexually attractive.

Whilst it can be used that way, peng more broadly means something is generally attractive / appealing / impressive. It doesn’t necessarily have sexual connotations.
wdyt about gnip (reversed ping) as an alternative to peeng?
There was a site/service called gnip.

https://en.m.wikipedia.org/wiki/Gnip

Man gnip was wild. I remember getting access to the Twitter firehouse for a while through this service. We built some really useful stuff with this.
Interesting. I gave Python training to a UK guy in the finance industry, a few years ago. He was working on a fintech side project that used gnip.
Or "Gneep" maybe
Does this tell me more than just cron is running on my site? Like what if my HTTP server has choked?
Can you elaborate? You are want it to ping your HTTP server and let you know when no response?
It tells you cron is running. It tells you your junior dev did not accidentally reconfigure your cron to go once a week rather than once an hour. It tells you that the program that cron starts, which performs a small suite of diagnostics on your website, is able to do them regularly. It tells you that the network at your remote office can reach the outside world.
Maybe like this, with HTTPie?

    http --check-status GET localhost/health && https GET example.peeng.sh
The point being that your internal healthcheck endpoint isnt exposed publicly.

https://httpie.io/docs/cli

<body> <ping> </body>
I would sign up if you allowed me to ping a 2nd “check status” endpoint then send the results in the POST.
you give us an URL to check, we HTTP-ping it and then send the results to another URL?
"peeng", "pee-pee-df" what is going on on HN the past few days?
We're used routinely to calling things crap. What's wrong with a wee bit of fun?
I really like this idea, but. I've been thinking about this, and also the fact that Pingdom, etc. seem to consolidate. Is there really a big market for "simple monitors"? If you are small, you probably don't care much/do it yourself/don't want to pay. The moment you grow bigger, you have many more comprehensive options available to you like Sentry, Datadog, PD, etc. that offer not only uptime alerts but all kinds of other stuff for a range of budgets.
true. the way we see it is that we will few use cases with very good UX, and the second thing is to build integrations to all other tools. think of status page that is integrated with all of your observability tools + you can add your own checks.
I use a similar service (healthchecks.io) to alert me if my backup jobs haven't succeeded in the past 5 days.

* rsync photos from phone to NAS (via Termux and Wireguard)

* btrfs-send from desktop to NAS

* restic from NAS to Backblaze

The integration is simple (just a HTTP request) and it notifies me via ntfy.sh and email.

any feature you would want and you don't have?