API requests blocked at CloudFront (403 "Request blocked")

SonarQube Cloud
1

Hello

All Web API requests for my account, org key : smallklauss are being rejected at the CloudFront edge with an HTML 403 — The request could not be satisfied / Request blocked, rather than a normal API response. I believe my usage pattern may have tripped an automated abuse rule, which was never my intent. Could you please review and lift the block, and advise on an acceptable usage envelope so I don’t re-trigger it?

I’m running an academic study on technical-debt prioritization over the history of some open-source Apache projects. For each tracked issue, scan a “before” and “after” commit to measure the change in code-quality metrics.

The pipeline’s footprint almost certainly looks abuse-like and I’m sorry for that, I create a separate public project per issue (before/after analyses), which over the study means a large number of short-lived projects. I also run up to ~10 GitHub Actions runners in parallel for throughput, which produces bursty API volume.

Can you pleae review and potentially lift the block if confirmed to be the case and not something on my end.

Would you also instruct me on what usage envelope is acceptable so I stay within bounds going forward?

Finally is there an academic/research or education arrangement that fits this kind of workload?

Happy to share more details about the workflow privately if that would help accommodate my request.

Thank you very much in all cases for your time!

Mohamed Amine Akhayat - Hangzhou Dianzi University

2

Hello @SmallKlaus,

Welcome to the Community!

Looking into the logs I believe the block is temporary, and should be automatically lifted once request volume from an IP drops below the threshold in the sliding window.

To avoid re-triggering it, some suggestions for your workflow:

  1. Throttle between API calls by adding a delay (even 200–500ms) between sequential requests. Ten parallel runners each making rapid-fire calls adds up quickly from a per-IP perspective.
  2. Reduce parallelism and consider running 3–4 parallel runners rather than 10. The throughput reduction is modest but the IP-level burst drops significantly.
  3. Reuse project data where possible. If multiple pipeline runs query the same org-level endpoints (project list, rules, settings), cache those responses locally rather than fetching fresh each time.
  4. Avoid ps=500 in tight loops. In the logs we see /api/projects/search?ps=500 being polled repeatedly within seconds. Bulk-fetching once and caching avoids this.

I’ll flag this for our internal Platform team, and have them comment on your other questions.

Cheers,

Stevan