The service is receiving too many requests from you Too many requests, possible issue on schedul trigger?

Questions
1

I have this strange issue on schedule trigger some one can help ?

2

idk maybe is an issue related to HTTP REQUEST ?

3

after last version update the http request retunr always 429 too many request

EDIT: it seems now if i start manually the workflow return execution fail with sam error and issue but after few seconds return the data

image
image1952×1004 77 KB

4

Hi @mredodos To avoid the bug generating rapid triggers every millisecond duplicate triggers and 429 error you can do one of the two either add a “Batching” in the HTTP Request node with a interval of 1000ms,or run the workflow manually once keeping the Schedule Trigger disabled.

1 Like
5

Hi @mredodos

Just to clarify: this isn’t a bug in the Schedule Trigger.

What’s happening is expected behavior — the workflow is making multiple HTTP calls in a short time, and the external service enforces rate limits and returns 429.

Batching or disabling the Schedule during manual tests helps, but the proper fix is to handle rate limits explicitly on the HTTP Request node: enable Retry on Fail, add a retry interval/backoff, and avoid parallel requests to the same endpoint.

This way the workflow remains stable regardless of whether it’s triggered by Schedule or manually.

1 Like
7

With batching or without, it doesn’t change the issue, and this issue trigger is just via a schedule trigger. Manual triggers work normally.

EDIT: cloudflare is bypassed. Browserless is set for multiple connection and concurrency session.
So what else can I try? I’m sure it’s a bug in the trigger or the HTTP node. But please tell me what else I could try.

Change retry on fail not work and not help.

8

Thanks, but no help. I have tried with or without.

EDIT:

image
image2332×985 485 KB

9

@mredodos if that is the case, have you tried checking the rate limits of the service you are using? and what there documentation says? As this confirms the schedule trigger is not the load here but the service you are using might be causing have you tried switching to a different account on that service and using those credentials? Let me know if this helps.

1 Like
10

The service im using is a self hosted service with my custom limitations and is not reached. At all…

I’m checking further and further. I hope I found a solution.

Maybe I can try to move the service in a specific new server.

11

Maybe then it is a tunnel issue, just use a more reliable tunnel and also a good hardware.

1 Like
12

It was currently on a Hetzner VPS with dedicated resources, with 16 GB of RAM and 8 vCPUs.

Cloudflare and Traefik are all set not to block anything from n8n.

13

@mredodos It’s working on my end without any issues on a self-hosted Browserless instance,

image
image994×821 65 KB

Are you self-hosting or using the cloud version?

You probably need to adjust some env vars (like CONCURRENT / MAX_CONCURRENT_SESSIONS) if you’re hitting a limit on a self-hosted setup,
Check out the essential configuration here:

1 Like
14

I need to understand why. I use Browserless in various workflows without any problems. And of course, I already set up all the environments. I’ve been using Browserless with the same installation for over a year. But thanks.

15

I think it’s obvious as explained here:

image
image991×286 26.4 KB

You are getting The service is receiving too many requests, which is explained in the Browserless documentation,

At this point, this is most likely a misconfiguration, not something related to n8n or the trigger node.

It’s simply how your logic is calling the Browserless endpoint, making too many concurrent or rapid requests without taking Browserless rate limits into account.

1 Like
16

I have located the issue. is related to the server; it seems to be going full CPU or RAM and returning that error.

1 Like
17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.