Palantir Foundry Incident Response

Overview

Protect data integrity and access controls while restoring service. Classify the failing Foundry surface, preserve request/build/release evidence, apply the least risky reversible mitigation, and validate recovery before closing.

Prerequisites

• Name the incident commander, technical owner, data owner, communications owner, severity, affected resources, and start time.
• Capture request IDs, build IDs, branch/commit, product or artifact version, module state, and recent approved changes.
• Read references/official-docs.md and the target enrollment's operational procedures.
• Confirm the rollback authority and protected-data handling rules before collecting logs.

Current Contract

• API 429 or 503 can represent rate or concurrency limiting and should receive bounded backoff rather than an unbounded retry storm.
• Transform build reports and metrics distinguish queue, CPU, memory, dependency, and data-related failures.
• DevOps/Marketplace release management can retain prior versions and support controlled upgrades or rollback.
• Logs may expose sensitive content and require explicit log access plus appropriate markings.