Logging

Each replication run writes a connector log below:

~/.pipelinewise/<target_id>/<tap_id>/log/

The filename is <target>-<tap>-<YYYYMMDD>_<HHMMSS>.<engine>.log.<status>.

Filename fields

Field	Values
`engine`	`singer` or `fastsync`.
`status`	`running`, `success`, `failed`, or `terminated`.
Timestamp	UTC run start time as `YYYYMMDD_HHMMSS`.

FastSync and Singer portions of one run_tap can write separate files. Keep both when diagnosing an initial-load failure.

Observe a run

Find and follow the active log:

find ~/.pipelinewise/<target_id>/<tap_id>/log -name '*.running' -print
tail -f ~/.pipelinewise/<target_id>/<tap_id>/log/*.running

Use --extra_log to mirror connector output to the invoking terminal:

pipelinewise run_tap \
  --tap <tap_id> \
  --target <target_id> \
  --extra_log

Diagnose failure

Collect these together:

the complete .failed or .terminated log;
pipelinewise status output;
the tap and target IDs and connector versions;
the last successful log;
source and target database errors at the same UTC time; and
whether state.json changed and which bookmark it contains.

Do not remove a .running file or PID file to make a live pipeline appear stopped. Use stop_tap, then confirm the process tree has exited.

Retention

PipelineWise does not provide a log-retention policy. Apply filesystem or platform retention that preserves enough successful and failed history to cover the maximum investigation and recovery period. Never delete runtime state while rotating logs.

See Troubleshooting for known errors and Stream buffering and acknowledgement for interrupted-run recovery.