Launching V2: Bubble-first external scheduler with callbacks, dashboard & security

[vip.ferries]

We’re releasing External HTTP Scheduler for Bubble (V2)—a Bubble-first, external scheduler that runs on Google Cloud Tasks and Cloud Run. It lets you plan HTTP calls that don’t depend on your app’s uptime, while giving you per-job visibility (status, latency, logs) and control (cancel, reschedule, quotas). No cloud setup; we operate and pay the infra.

What’s in V2
V2 focuses on reliability, clarity, and speed to integrate. The server action (“Schedule webhook”) accepts your URL, method and payload, plus an optional native callback to update a Bubble Thing once the webhook returns. Everything runs outside your Bubble runtime, so scheduling is resilient and independent. When a job fires, you’ll see real-time state, HTTP status, and latency in the dashboard, with cancel/reschedule just a click away.

Dashboard narrative

Your team lives in a clean dashboard: incoming jobs appear queued → running → success/failed/cancelled/skipped with run_at, webhookStatus, latencyMs, and any lastError for fast triage. Need to stop a run? Cancel prevents dispatch. Want to re-use a request? Clone (or retry if appropriate) keeps iteration fast. Usage shows month-to-date vs included.

Security & privacy

Zero cloud setup on your side; we operate.
Sensitive headers (e.g., authorization, cookie) are filtered before execution.
Requests execute server-to-server with signed identity. Anti-SSRF protections, DNS/IP validation.
We log status/latency/errors, not your secrets.

WU clarity

Scheduling is fully external → 0 WUs.
If you use the optional callback to update a Thing via Bubble’s Data API, that write-back consumes WUs (same as an API workflow). Transparent and expected.

Pricing

Single plan: $19/month for 1 Bubble app.

Included quotas: ~1M jobs/month per app.

E-mail alerts are capped at 5/day/app.

Short demos

— Call API Now Action

Create an instant job, dispatch externally; no setup.

— Schedule Webhook Action

Schedule an API call with headers/body, then monitor status, code & latency.

— Dashboard

Monitor every job in real-time; cancel, retry, reschedule with one click.

Try it now: Webhook Scheduler Pro — Schedule your webhooks with ease
Docs: webhookscheduler.com/docs
Plugin Page: Webhook Scheduler Pro Plugin | Bubble

Questions & feedback welcome below

[georgecollier]

@vip.ferries

WU clarity

Scheduling is fully external → 0 WUs.

Well that’s clearly untrue:

@vip.ferries

The server action (“Schedule webhook”)

No offence, but I’m so, so confused by why this tool exists.

It doesn’t save WU, it increases complexity, and introduces reliance on a third-party with no history in the community.

Unfortunately, the people that really do want certain enterprise protections etc will want to run this themselves rather than send all their data to a mystery operator.

[vip.ferries]

You’re right that the initial server action ≠ 0WU. The difference is what happens after that: all retries, delays, and monitoring run fully outside Bubble (Google Cloud Tasks + Cloud Run).

So for jobs that would normally require hundreds or thousands of WUs via recursive workflows, you’re down to a single trigger WU. That’s the core efficiency.

Regarding complexity: the goal isn’t to add more moving parts, it’s the opposite, agencies don’t have to build retry logic, failure monitoring, or concurrency locks themselves.

Infra isn’t a “mystery operator”: everything runs on GCP, with logs limited to status/latency/errors only.

I’m happy to share metrics transparently to build trust. Agencies can spend time reinventing retries and monitoring, but here it’s already built and battle-tested.

[Jici]

Maybe you can explain a little bit more and give some case/example because actually, I’m on @georgecollier side.

[vip.ferries]

Good point Jici, let me give a few concrete examples where this is useful beyond Bubble’s native scheduler:

• Recurring billing / subscriptions : 10,000 invoices sent monthly. With recursive workflows, that’s a lot of WUs + no retries if an API call fails. Here, it’s 1 WU at trigger, then all retries/backoff/monitoring handled externally.

• API sync every few minutes (e.g. Shopify or Airtable) : native scheduler can be expensive and unreliable under load. Here, jobs are queued outside Bubble with concurrency locks, no duplicates, no missed runs.

• Bulk notifications (e.g. push/email/SMS) : 50k+ jobs spread over hours. Instead of burning WUs for each step and losing visibility, you get real-time dashboard, success/failure logs, retry on error.

All the technical details are here: Documentation - Webhook Scheduler Pro

If you want, I’m happy to provide you a free trial key so you can test it on a real use case and see if it fits your workflows.

[Jici]

There’s a lot of thing in what you suggest that refer to recursive WF, that, since the new version of schedule on a list, is not needed anymore and can already save a lot of WU (bulk notification, recurring billing…) or for recurring billing, with Schedule a recurring event.

For API Sync, I don’t see any advantage as you will probably query Bubble DB. And with a good structure, even if you are using webhooks, you shouldn’t have concurrency issue. More than that, even if you queue item on your side, it doesn’t mean callback cannot create concurrency issues (however, like for regular callback, there’s way to fix that)

As for API call fails… this can be solved in Bubble but I agree this will increase WU cost.

You have an example in your doc (simple one):

Instantly get data from an external API. Let’s fetch the current temperature in Paris using the free Open-Meteo API. This example is best suited for the Call API Now action.

1. Set Endpoint to: https://api.open-meteo.com/v1/forecast?latitude=48.85&longitude=2.35&current_weather=true

2. Set HTTP Method to GET.

3. To get just the temperature, set Response Path to current_weather.temperature.

4. The action’s returned value `selected_value` will now contain the current temperature, which you can display in a text element in Bubble.

Why should I use your service for this kind of request?! Your (I guess / I hope…server side) action will cost me more than calling directly the API probably! And what about the complexity to work with data back from it after? (Where API Connector will simply parse it…)

Above that, I have serious doubt about security/privacy of the whole process…

[vip.ferries]

Thanks Jici, fair points. Let me clarify the boundaries so we don’t talk past each other.

1) When Bubble native is enough (I agree):

• Schedule on a list (new engine) and Schedule a recurring event cover simple/medium batches well and already save WUs vs old recursives.

• Immediate API calls (like the Open-Meteo example) : use API Connector. My tool is not for trivial GETs; that example is in docs to illustrate Response Path, not to argue cost wins on a single call.

2) Where an external scheduler is still valuable (the wedge):

• High-volume / long-running pipelines beyond a day or with spiky traffic (tens of thousands of jobs spread over hours/days).

• Reliability features not available natively: retries with exponential backoff + jitter, dead-letter queue, per-tenant concurrency locks (idempotency by key), per-route rate limits, and operational visibility (status/latency/error logs).

• Fault isolation: scheduling/execution continue even if the Bubble app has an outage or a deploy hiccup.

• Cost predictability: 1 WU at trigger; the pacing/retries/run-later happen off-app.

3) On “API sync + DB queries = no advantage / concurrency doubts”

• If your pipeline is purely in-app and small, agreed: native is fine.

• Where we help is back-pressure and pacing when an upstream API is flaky/slow or you need per-tenant throttling. You can push 50k intents to the queue and let Cloud Tasks pace them with key-based locks so you don’t process the same tenant twice in parallel.

• Callbacks can indeed re-introduce concurrency in Bubble. We mitigate with idempotency keys (you pass job_key or entity_id+timestamp; we deliver once; Bubble checks and ignores duplicates). Happy to show a minimal idempotent workflow.

4) Security & privacy (your last point):

• Infra: Google Cloud (Cloud Tasks + Cloud Run, regional). TLS 1.2+.

• Auth: HMAC-signed server-to-server requests with per-app secret; optional IP allowlist.

• Data handling: we don’t persist payload bodies; logs store only status / code / latency / error snippet.

• Retention: logs 30 days (configurable); encryption at rest by GCP.

• We’re not claiming SOC2 today, being transparent on the current scope. If you need stricter controls, we can walk through them.

So,

• Use Bubble native for immediate/simple and many medium jobs, absolutely.

• Use external when you need retries/backoff, idempotency, pacing, monitoring, and fault isolation at higher volumes or over longer windows.

I’m happy to share metrics (p95 dispatch latency, retry behavior under upstream failures) and give you a trial key to run a real scenario you care about. If it doesn’t add value in your case, I’ll be the first to say “stick with native”.

[Jici]

Thanks and this help to understand more the market you are targetting with this plugin.

[vip.ferries]

Glad it clarified, that’s exactly the use case we’re focusing on. Happy to share more if you (or any agency) want to try it out in real workflows.

[sem]

Reading from the number of comments and the content of the comments it might be that bubble users and agencies are not the best fit. I think anyone with lots of hands on experience with very large and complex applications know what you are talking about. Good luck with the product! Would be great if you get many customers as it probably means that Bubble attracts many enterprise complex application builders

[mario11]

Not only that. But is what is managed externally really free? I wouldn’t be so convinced.

[senecadatabase]

This is using Nimbus? I would guess it is.

Either way, if someone is building a complex app, this would be a no-brainer to use if it works as you’ve described

[vip.ferries]

We run everything on Google Cloud Tasks + Run, so yes, there’s infra cost. The difference is that it’s tiny compared to Bubble WU pricing. That’s why it’s bundled: the $19/mo plan includes up to 1M jobs/month, with predictable overage after that. For users it feels “WU-free”, because the infra is already covered.

[vip.ferries]

Thanks a lot , totally agree. Native scheduling works for most small/medium apps, and that’s fine. The real value here shows up in very large or long-running workflows where retries, pacing and monitoring matter. If Bubble attracts more enterprise-grade apps, this is exactly where it helps.

[mario11]

I might as well agree. But from a commercial point of view I think you are in a really bad position. It’s not a criticism, just a feedback.

[vip.ferries]

Thanks Mario, just to clarify: the infra cost is calculated and included in the monthly plan. That’s precisely why it’s packaged as a subscription.

On Google Cloud, running 1M jobs costs only a few euros (fractions of a cent per 1k tasks). So even with the $19/mo plan including up to 1M jobs/month, the infra expense stays very low relative to the value.

The point of the pricing isn’t to give away infra “for free” but to make it predictable, agencies know exactly what they pay, while we absorb the tiny infra cost.

[ihsanzainal84]

I can see where you’re going with this. I am also very sure someone else built a similar service and promoted it in the forum not too long ago. Though they were kinda iffy about security IMO.

I’ll just echo the point about your target demographic though. Not sure there’s a middle ground between “Bubblers who don’t need that level of complexity” and “Bubblers who need it and can build their own stack”.

Other than pricing, what does your service offer that something like Zapier can’t do? Zapier is really easy to use and is appealing to Bubblers because they are both no-code workflow builders

I can totally see the use case for what you built, because I built the same kind of stack to handle serialization and atomicity for my apps. I’m your target demo but at the same time I am not.