Serverless functions returning empty 403s at the edge — never invoked (production outage)

Support
, ,
1

Project: thepointsplanner (custom domain: thepointsplanner.com) · Team: hayden-tpp · Pro plan, billing in good standing

Since approximately 8:30 AM PDT on July 29, every externally-originated request to our serverless function endpoints (/.netlify/functions/*, plus /api/* redirects to functions) is rejected before the function is invoked:

  • ~8:30 AM – 12:45 PM PDT: empty-body 500 responses
  • ~1:00 PM PDT onward: empty-body 403 responses (content-type: text/plain, content-length: 0, server: Netlify)

Our function logs show zero invocations for any of these requests — the responses are coming from the edge, not our code (our own 403s return a “Forbidden” body and write a log line; these do neither).

Every external source is affected:

  • Our cron scheduler (cron-job.org) — worked flawlessly since May, last successful run 8:15 AM PDT Jul 29
  • GitHub Actions runners
  • curl from a residential IP (with and without a browser User-Agent)
  • Even a same-origin browser fetch() from our own site’s console

Meanwhile:

  • Static content serves normally on both thepointsplanner.com and thepointsplanner.netlify.app
  • Internally scheduled function invocations still execute — the block is specific to externally-originated function requests
  • Both domains behave identically

Nothing changed on our side: no deploys since Jul 28 (the block began mid-day Jul 29 with no deploy), no environment variable changes since Jun 9 (confirmed via audit log), no Firewall Traffic Rules, no Rate Limiting, WAF disabled, ample credits remaining this billing period.

Sample blocked request IDs:

  • 01KYR75R6TRYYK1BSSQ7GCF0BS — 2026-07-30 00:35:46 UTC
  • 01KYR77FSW47WKJZRHZ95S0H10 — 2026-07-30 00:36:43 UTC

Business impact: this is a production outage for us — Stripe payment webhooks are undeliverable (customers pay and don’t get activated), all transactional email crons are down, and client-side function calls fail.

Has Netlify recently rolled out edge-level bot/abuse protection that could false-positive an entire site’s function traffic? Can staff check what flag or rule is intercepting these requests and lift it?

A support ticket has been filed as well; posting here since the block escalated during the day (500s → 403s) and we’re hoping someone can trace those request IDs quickly.

2

Hey @Haydsamp26, thanks for getting in touch, and apologies for the hassle here! It looks like we’ve followed up in the internal thread that you referenced, but please don’t hesitate to reach back out if there’s anything else we can look into.