Cortex Data Lake (Palo Alto)
What HTTP errors mean when ingesting from Palo Alto Cortex Data Lake or XSIAM, what the operator should actually do, and how confident we are in each interpretation.
Why this page exists
On April 14, 2026 a Setu customer's Cortex Data Lake adapter returned 401 Unauthorized on every API call for the entire day. Their administrator had no notification. Their security posture view kept rendering as if data were flowing. The actual cause: Palo Alto had silently throttled their tier after they exceeded the 166 credit-units-per-day quota that ships with the standard XSIAM contract. The 401 is how Palo Alto signals quota exhaustion. It is not how most operators expect quota exhaustion to be signaled.
This page documents that, plus the other failure modes we have either observed in the field or seen in Palo Alto's documentation. The catalog is MIT-licensed open data; if you operate Cortex Data Lake or XSIAM, you can read it, cite it, or fork it without asking.
401_after_sustained_trafficHTTP 401 after sustained traffic
Cortex Data Lake or XSIAM returned 401 Unauthorized after a period of healthy traffic. This typically indicates your Palo Alto credit-unit budget has been exhausted for the current billing period. The API is silently throttling rather than returning a 429 Too Many Requests.
Check Palo Alto admin console → Tenant Management → Credit Usage. If the budget is exhausted, contact your Palo Alto account team to request a tier increase or wait for the next billing period reset.
401HTTP 401 (no recent successful traffic)
Cortex API returned 401 Unauthorized without prior healthy traffic in the same period. Your API key may be invalid, expired, or have been rotated.
Verify the API key in the Palo Alto admin console under Settings → Configurations → API Keys. If recently rotated, update the key in your ingestion source configuration.
429HTTP 429 Too Many Requests
Cortex rate limit exceeded. This is the cleanly-documented throttling path; the silent-401 path above is the field surprise.
Reduce poll frequency in your ingestion configuration, or contact Palo Alto for a quota increase.
Retry policy
max_attempts | 10 |
initial_backoff_ms | 500 |
max_backoff_ms | 60,000 |
factor | 2.0 |
jitter | 0.25 |
retryable_status_codes | [401, 429, 500, 502, 503, 504] |
respect_retry_after | true |
cooldown_seconds | 300 |
Why 401 is retryable: the canonical April 14 scenario above. A 401 from CDL after sustained traffic usually means transient quota exhaustion, not a bad token; the next billing period reset (or a tier increase) restores the same credentials. Treating 401 as fail-fast would mean a permanently stalled adapter where a 5-minute cooldown would have recovered.
Confidence and evidence grades
Each interpretation carries an evidence_class that tells you how we know it:
- observed_in_field — we have customer logs of this exact failure mode on this exact endpoint, and traced it back to root cause.
- vendor_documented — Palo Alto's official documentation describes this case explicitly.
- inferred — we reasoned from generally applicable HTTP semantics; no observed case yet.
- community_reported — another operator reported this; we have not independently verified.
If you operate CDL and have a failure mode we missed, open an issue or MR on the catalog repo. Real-world observations grade up over inference.