Hey folks! Shahar and Tal from Keep (<a href="https://www.keephq.dev">https://www.keephq.dev</a>) here!<p>For the last few weeks we’ve been building Peeng and can now share our beta with you: <a href="https://www.peeng.sh" rel="nofollow noreferrer">https://www.peeng.sh</a>. 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.<p>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!<p>Quick demo: <a href="https://youtu.be/ZX5mrnMRCwU" rel="nofollow noreferrer">https://youtu.be/ZX5mrnMRCwU</a><p>Why we built this:<p>- We needed an easy way to let Keep (<a href="https://github.com/keephq/keep">https://github.com/keephq/keep</a>) 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<p>The beta version lets you:<p>- 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<p>What’s next:<p>- 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”: “<a href="https://..”" rel="nofollow noreferrer">https://xn--ivg</a>, “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)<p>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 :)
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.)<p>The blurb on the site was difficult for me to parse, mentally. It's wordy and awkward with the negative in there:<p>> Receive an HTTP request whenever your heartbeat endpoint is not pinged for a configured interval of your choice.<p>"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"?)
A service in a very similar vein is <a href="https://healthchecks.io/" rel="nofollow noreferrer">https://healthchecks.io/</a> - which also provides a nice perspective on how low-effort the setup for a service with a substantial amount of users can be. <a href="https://news.ycombinator.com/item?id=31488910">https://news.ycombinator.com/item?id=31488910</a><p>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.
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?
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.<p>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.<p>[0] <a href="https://en.wikipedia.org/wiki/Dead_man%27s_switch" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Dead_man%27s_switch</a>
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?".
I been looking for a reverse of pingdom and this post has caught my eye but not sure if it does what I need.<p>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.<p>Does anyone know of which?
I don’t currently need something like this, but I like the simplicity and it seems handy.<p>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.<p>Edit: the menu button on the landing page doesn’t work for me on iOS.
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.
the name suffix suggests that it is implemented as a shell script.<p>the homepage does not convey any information about this script or anything else like setup instructions.<p>if i click on the github links in the top row i see a codebase that is supposedly for the server side.<p>i would like to know more but you're not making it easy.
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.<p>Edit: or maybe redirect mobile visitors from peeng.sh to your .dev site.
I use a similar service (healthchecks.io) to alert me if my backup jobs haven't succeeded in the past 5 days.<p>* rsync photos from phone to NAS (via Termux and Wireguard)<p>* btrfs-send from desktop to NAS<p>* restic from NAS to Backblaze<p>The integration is simple (just a HTTP request) and it notifies me via ntfy.sh and email.
Sounds like <a href="https://deadmanssnitch.com" rel="nofollow noreferrer">https://deadmanssnitch.com</a> with a bigger free plan, or is there a fundamental difference?
I like your product but your pricing per endpoint is not what I would choose:<p>10 endpoints - $1 per endpoint per month<p>20 endpoints - $1.5 per endpoint per month<p>30 endpoints - $1.33 per endpoint per month
Congratulations on shipping!<p>It's not really clear how this is different to heartbeat monitoring, is it because it uses a subdomain instead of a URL path?
we're now available at <a href="https://www.gnip.io" rel="nofollow noreferrer">https://www.gnip.io</a> (or gnip.app or gnip.dev)