Email Personalization / Render Failure
Debug an email that fails for some recipients or builds too slowly because personalization is fragile or expensive.
Evidence tier describes my hands-on relationship with the content. Official sources describe platform contracts/documentation. Production observations should not automatically be treated as official limits.
Find the failing recipient shape
Compare a working row and a failing row: missing keys, null attributes, malformed values and lookup cardinality.
Replace direct assumptions with defensive reads
Use AttributeValue/Empty guards where missing attributes should fall back instead of crashing.
Guard rowsets before Field()
Check RowCount before Row/Field access. Missing lookup rows are a common per-recipient failure path.
Bound lookup cardinality
LookupRows returns at most 2,000 rows; rendering huge one-to-many relationships is usually an architecture smell.
Inspect remote calls
HTTPGet/remote personalization can turn message building into a network dependency and degrade Journey throughput.
Use RaiseError only for real invariants
Skip a broken recipient when needed, but do not use RaiseError as segmentation logic.
Move expensive work upstream
Precompute reusable data in SQL/Automation Studio when the same logic runs for every recipient.