← Documentation: Reliable Backup & Sync Execution Validation (Log-Driven)
Validate with synthetic logs and a test inbox before relying on scheduled alerts. Test the monitor's decisions independently of your production backups.
Upload one log with complete markers, zero errors and a successful return code. Ensure its filename appears in the manifest. The execution should process it without a failure alert.
Then run several logs together and confirm each is evaluated once. Check the date prefix, timezone and upload cutoff at a day boundary.
Omit an expected file: the missing-log email should identify its name. Separately, submit a nonzero return code and a log without END; these should follow the execution-error path.
Use a synthetic AI finding to verify valid JSON and the intended Gmail action. Test duplicate expected filenames and invalid manifest JSON as configuration failures. An empty GCS prefix should not lead to an undefined-object download.
Every log appears missing: compare the bucket, sync-logs/ prefix, hostname, UTC date, upload timing and exact manifest basenames.
GCS access fails: check list/read permissions and credentials in both GCS nodes. Uploader access does not establish n8n reader access.
GitHub JSON fails: inspect repository permissions, path, JSON syntax and base64 decoding.
False positives: inspect lifecycle markers and whether the job was due that day. Compare frequency, cron_time, weekly days and monthly windows with the implemented rules.
AI errors or noisy alerts: inspect model JSON, IF outputs and loop wiring, then retest with synthetic input.
Keep the bucket private, use scoped service identities and store secrets in credentials. Set log retention and access auditing appropriate to the operational data.
Enable independent execution-error alerts so failures in the monitor are visible. Continue periodic restore tests: log validation cannot establish destination recoverability.