Possible false-positive DDoS mitigation blocking authenticated Preview requests

Hi Vercel team,

I am seeing repeated Vercel Security Checkpoint HTTP 403 responses on disposable Preview deployments in a Hobby project.

Observed behavior:

A same-origin GET /api/health was issued from the logged-in project owner's browser.
The response was HTTP 403 with Cache-Control: private, no-store, max-age=0.
Favicon requests from the same deployment also returned 403.
A bounded runtime-log query found zero matching application requests, indicating that the request was blocked before reaching the deployment runtime.
The project Firewall overview showed zero project-level Denied or Challenged requests.
Bot Protection was inactive and there was no relevant custom deny/challenge rule.
The Firewall overview showed a system DDoS Mitigation denial.
Protection Bypass for Automation did not resolve similar previous blocks.

The application route is expected to return HTTP 200 with: {"service":"skyframe-web","status":"ok"}

The route contract passes locally and the same endpoint has previously returned HTTP 200 on a disposable Preview.

Could a Vercel team member confirm whether this is a false positive and advise how a Hobby user can prevent authenticated owner-controlled Preview health requests from being blocked, without weakening Production security?

I can provide the project ID, deployment hostname, and exact timestamp privately to Vercel staff if needed.

Following up because this is still blocking our canonical health verification. Requests to /api/health consistently receive a platform-level 403, while no application runtime logs are generated, indicating that the request is blocked before reaching the deployment runtime.

Could a Vercel staff member please escalate this for review of the DDoS mitigation decision and confirm whether it is a false positive? I can provide sanitized request timestamps and response/request IDs privately if needed.