Product upvotes vs the next 3

Waiting for data. Loading

Product comments vs the next 3

Waiting for data. Loading

Product upvote speed vs the next 3

Waiting for data. Loading

Product upvotes and comments

Waiting for data. Loading

Product vs the next 3

Loading

gniP

Reverse Ping - Pingdom/Cronitor alternative, quick & easy

Pingdom/Cronitor free alternative (but the other way around and A LOT simpler, with A LOT more capabilities), suitable for developers, system admins, DevOps, and individuals with complex networking situations (think “onprem” or K8s clusters with no inbound).

Top comment

Hey Product Hunters! Shahar and Tal from Keep (https://www.keephq.dev) here! 👋 For the last few weeks we’ve been building Gnip 🚨 and can now share our beta with you: https://www.gnip.io. Gnip is the easiest and quickest “heartbeat” architecture we could think of. Just pick a subdomain (e.g. x.gnip.io), configure an interval, an endpoint, and a payload, and hit that subdomain every (less then) X (interval) seconds — If you won’t, Gnip will send an HTTP POST request to your configured endpoint. Get POSTed when your subdomain stops receiving pings for a configured interval of your choice! 🧙‍♀️ 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 — Gnip presents outbound heartbeat checks, Reverse Ping! 👀 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-gnip-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 gnip.io/subdomain -H API_KEY —json {”subdomain”: “hn”, “endpoint”: “https://..”, “payload”: {…}}) - Hierarchy-based subdomains that allow you to create a nested heartbeat solution (i.e. dynamically create a heartbeat subdomain under x.gnip.io → y.x.gnip.io, z.x.gnip.io) 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 here or via Intercom :) 🫶🏼