## TL;DR
Fivetran does not truncate tables on its own outside of a re-sync, so an unexpected truncation means a re-sync was triggered, a hard-delete mode change took effect, or something else wrote to the table. Check the connector history for re-syncs and audit who else has write access. Recover from the warehouse's time travel or your backups, then lock down who can trigger re-syncs.

```text
fivetran destination table truncated unexpectedly, how to fix
```

## Use this when
- A destination table is suddenly empty or much smaller than expected.
- Row counts dropped to zero after a sync.
- Downstream models fail on the empty table.

## Not for this skill when
- You triggered a re-sync yourself. The truncation is expected; wait for it to finish.
- The table is small because the source is small. Check the source first.

## Steps
1. Check the connector history for re-syncs, mode changes, or table resets around the truncation time. Note the triggering event. Verify: the trigger is identified
2. Audit warehouse write access: who else can truncate or drop this table? Note the other writers. Verify: other writers are found or ruled out
3. Recover the missing rows with the warehouse's time travel or by cloning from before the truncation, or restore from backup. Note the recovered row count. Verify: the data is restored
4. Let the connector re-sync if needed to catch up from the recovery point. Note the sync completes. Verify: the pipeline is current again
5. Restrict who can trigger re-syncs and alert on unexpected truncations. Note the guardrails are in place. Verify: recurrence is prevented

## Variant phrasings
### fivetran table empty after sync
The symptom phrasing.
### fivetran resync truncated table
The cause-shaped search.

Compatibility: All Fivetran connectors and warehouse destinations. Time travel availability depends on the warehouse.

## Why it happens
A re-sync rebuilds the destination table from scratch, which starts with an empty table that fills as the sync progresses. If anything interrupts that sync, or if someone mistakes the mid-sync empty table for the final state, it looks like data loss. Genuine unexpected truncations are rarer and scarier: a mode change to hard delete, a table reset by another admin, or a different tool writing to the same table. The connector history distinguishes a re-sync (expected, recovers) from a mystery (investigate).

## Edge cases / pitfalls
- Querying a table mid-resync shows partial data. Check sync status before concluding data is lost.
- Time travel windows are limited (often 1-90 days). Recover quickly or the window closes.
- Hard-delete mode plus a source that reports all rows as deleted truncates effectively. Verify source delete signals before enabling hard delete.
- Downstream models that ran against the empty table may have written empty results onward. Check and repair the downstream chain too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Tsm8pGuFnuLjw5n8tP79aQ