This product was not featured by Product Hunt yet.
It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
Product upvotes vs the next 3
Product comments vs the next 3
Product upvote speed vs the next 3
Product upvotes and comments
Product vs the next 3
getNodi
Every run. On the second. On the record.
getNodi calls your endpoints on a schedule, retries them when they fail, and keeps the status, latency and response body of every single attempt — and lets you decide what counts as a pass, so an empty 200 is a failure if you say it is.
Top comment
What inspired you to build this? Every project I've ever shipped eventually needed the same thing: "hit this URL every 15 minutes." Nightly cleanups, report generation, cache warming, syncing data between services. And every time, the options were the same — a crontab on a server I'd forget about, a serverless cron with tight limits on frequency and duration, or a heavyweight workflow engine that's overkill for "call an endpoint on a schedule." The tipping point was hitting the ceiling on hosted platform crons — limited schedules, short timeouts, no retries, and zero visibility into whether a job actually ran. I realized the thing I kept re-building wasn't the job itself. It was the scaffolding around the job: auth headers, retries, alerting when it fails, and a history I can look at when something goes quiet. What problem were you trying to solve? Scheduled jobs are invisible until they break — and they break silently. A cron that stops firing doesn't throw an error anywhere; it just... stops, and you find out weeks later when the data is stale. getNodi is self-service cron-as-a-service: sign up, create a project, point a job at any external URL on a cron or interval schedule. Each run gets authorization, retries, alerting, and per-run analytics, so "did it run, and what happened?" is a dashboard, not an archaeology project. You can even give stakeholders a public status page for a job via a shared token — no login required. One design decision I care about: MongoDB is the source of truth; Redis is only a cache of what's currently scheduled. On boot, the worker reconciles the two. If the Redis volume is ever lost, every enabled job reschedules itself automatically instead of silently never firing again. That failure mode — the silent stop — is exactly the disease this product exists to cure, so the architecture had to be immune to it too. How did your approach or process evolve? Honestly, the product taught me what it wanted to be as I built it: It started as "getNodi" — a scheduler. Core loop first: Next.js dashboard, a BullMQ worker, jobs firing HTTP requests. Get one job to run reliably before anything else. Then it became about trust in operations. Once jobs were running, the real work was observability — redacted request/response logging, per-run metadata, hourly rollups, a monitoring dashboard for the worker fleet and queues. If the pitch is "know your jobs ran," the platform has to be transparent about itself. Then trust in the business. Rebranding to getNodi, and the unglamorous-but-essential layer: security and refund policies, a DPA, an admin dashboard, lifecycle emails, and billing with plan mappings verified against Razorpay rather than hardcoded — so pricing can evolve without a deploy. Self-hosting stayed first-class throughout. It's Docker Compose behind nginx, with a compose wrapper that auto-detects whether you're bringing your own MongoDB/Redis (Atlas, Upstash) or want the bundled containers. The Free plan carries every capability — the paid tiers are about scale, not gates. The biggest process shift: I stopped asking "what feature is next?" and started asking "what would make someone trust this with a job they'd forget about?" Every answer to that question — reconciliation on boot, run history, status pages, honest legal pages — became the roadmap.
About getNodi on Product Hunt
“Every run. On the second. On the record.”
getNodi was submitted on Product Hunt and earned 0 upvotes and 1 comments, placing #86 on the daily leaderboard. getNodi calls your endpoints on a schedule, retries them when they fail, and keeps the status, latency and response body of every single attempt — and lets you decide what counts as a pass, so an empty 200 is a failure if you say it is.
On the analytics side, getNodi competes within Developer Tools — topics that collectively have 518.8k followers on Product Hunt. The dashboard above tracks how getNodi performed against the three products that launched closest to it on the same day.
Who hunted getNodi?
getNodi was hunted by Dinesh. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
For a complete overview of getNodi including community comment highlights and product details, visit the product overview.