Underlayer
Catch, edit, and retry failed webhooks & cron jobs
13 followers
Catch, edit, and retry failed webhooks & cron jobs
13 followers
A developer-first task scheduler for HTTP webhooks, crons, and async jobs. Stop digging through messy server logs when things break. Underlayer catches failed payloads in a visual Dead Letter Queue. Easily inspect the error, fix the broken JSON right in our built-in editor, and hit retry with one click. Manage your team, monitor every run, and keep your backend infrastructure running smoothly without ever touching the CLI. Generous free tier available.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentGive every agent its own machine. Starts in under a second
Promoted
I like the visual DLQ angle a lot. Failed webhooks and background jobs are usually not the exciting part of building, but when a Stripe event, email job, or user action fails, suddenly you’re in logs, scripts, payloads, and stress instead of actually shipping.
Curious how you think about safety around editing payloads before retrying. Do you keep a full audit trail of what changed, who changed it, and what the original payload was?
@andrasczeizel Thanks! You hit the nail on the head. Nobody wants to spend their Tuesday morning digging through logs and raw JSON strings under stress.
To answer your question about safety and audits: yes, we took an immutable approach from day one.
The original failed payload is never overwritten. Whenever you edit and retry an event, the system creates an immutable clone with its own payload, mapping it to the parent task. This means the entire tree is fully navigable, and every single HTTP attempt logs the exact payload sent. Since we track who triggered the retry, you can always audit who sent what.
What we don’t have yet is a granular diff changelog (e.g., "User X changed field 'email' from A to B"). It's definitely on the roadmap for teams with strict compliance needs.
Funny you mention execution safety, alongside auditing, I am actually working right now on adding a native idempotency middleware layer to the execution engine. That way, if an external service like Stripe retries a webhook at the exact millisecond you hit "manual retry" in the UI, the system locks it down to prevent double-processing.
Really appreciate the thought-provoking feedback!