2 hours ago
Project ID: dc6cca44-52ba-4b3e-a5f7-2b918e8509a4 (prolific-light)
Service: JobSearchHelper (3e5f6b57-4e68-4a9f-9382-5e54d630364c)
Environment: production
Domains affected: getjobbed.dev (custom) and jobsearchhelper-production.up.railway.app (Railway-provided) — both show identical behavior
Issue:
Our edge is returning HTTP 429 to legitimate requests, including Stripe webhook deliveries to our own endpoint. Confirmed via response headers that this is coming from Railway's own edge, not a third-party proxy or anything in our app stack (no rate-limiting middleware/library anywhere in our code or dependencies):
curl -I https://getjobbed.dev/healthz
HTTP/2 429
content-type: text/plain; charset=utf-8
content-length: 12
x-hikari-trace: jfk1.57w5
server: railway-hikari
x-railway-edge: jfk1
date: Wed, 15 Jul 2026 18:16:46 GMT
curl: (16) Error in the HTTP2 framing layer
Two concrete impacts:
- Stripe webhook deliveries to https://getjobbed.dev/webhooks/stripe are being rejected with 429 by this system (confirmed via Stripe's own Event Deliveries log for a checkout.session.completed event around 2026-07-15 17:33 UTC), which breaks our billing integration — a live Checkout completed successfully but our app never received the webhook to activate the subscription.
- Real human visitors on a fresh/uncookied session (e.g., incognito) also hit an interactive "prove you're human" challenge before being let through. That's tolerable for browsers, but it's a structural dead end for any server-to-server integration (Stripe, or any future webhook-based integration) — there's no browser there to solve the challenge.
What we need: a way to exempt legitimate webhook/API traffic from this system — either:
- Path-based exemption for /webhooks/stripe, or
- IP-based exemption for Stripe's published webhook-sending IPs:
3.18.12.63, 3.69.109.8, 3.120.168.93, 3.130.192.231, 13.235.14.237, 13.235.122.149, 18.211.135.69, 35.154.171.200, 35.157.207.129, 52.15.183.38, 54.88.130.119, 54.88.130.237, 54.187.174.169, 54.187.205.235, 54.187.216.72
Happy to provide additional logs/deployment IDs if useful.
1 Replies
2 hours ago
Your service has Under Attack Mode enabled (set to stay on until manually disabled), which is what's producing the 429s and browser challenges. While active, all non-browser traffic is blocked at the edge, which includes Stripe webhooks and any other server-to-server requests. There is currently no path-based or IP-based exemption available. Disabling Under Attack Mode in your service's Settings > Edge section will immediately restore webhook delivery. The feature is designed for active DDoS incidents rather than always-on protection.
Status changed to Awaiting User Response Railway • about 2 hours ago
Status changed to Solved cmaloy12 • about 1 hour ago