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.

getNodi

Every run. On the second. On the record.

Every run. On the second. On the record.