Pick SignalBin when
- You want the provider registered against one URL that never changes.
- You need the payload from last Tuesday, and the tunnel is long gone.
- A teammate needs to see the same request without you rebuilding the setup.
ngrok exposes a port on your machine to the internet. That is the right tool when the code that must handle the request is running on your laptop right now. SignalBin is the opposite trade: the URL is hosted and always up, and the request is stored whether or not anything of yours is running.
ngrok connects a provider to your laptop. SignalBin catches what the provider sent so you can look at it later.
| SignalBin | ngrok | |
|---|---|---|
| What it is | Hosted receiving endpoints with stored history | A tunnel from a public URL to a local port |
| Uptime | Endpoint is up whether or not your machine is | Depends on the tunnel process staying alive |
| Request history | Stored, searchable, kept 30 days | Local inspector for the current session |
| Team visibility | Shared workspace history | Local to the machine running the tunnel |
| Reaching local code | CLI destination kind, or forward from a destination | Direct, by design |
| Provider setup | Register the URL once | Re-register when the tunnel URL changes, unless reserved |
This page describes what each tool is built for rather than tracking a feature matrix. For ngrok's current capabilities and pricing, check their own site. It is the only source that stays accurate.
Yes, through the cli destination kind, which lets a locally-running SignalBin CLI pick up captures and deliver them to a local address. That keeps the public surface on SignalBin rather than on your machine.
No, and plenty of setups use both: a tunnel while you are actively coding, a SignalBin endpoint as the URL the provider is permanently registered against.
Send a request, open the payload, and see exactly what your provider delivered.