n8n Facebook Automation: วิธีป้องกันโพสต์ซ้ำและจัดการ Error

คู่มือเชิงออกแบบและตัวอย่างจำลอง ไม่ใช่หลักฐานการโพสต์ Facebook Page จริง; ต้องตรวจสิทธิ์บัญชี Meta, API Version และการทดสอบก่อนเปิดใช้งาน.

ทำไม Workflow สีเขียวจึงไม่พอ

Facebook Automation มีผลภายนอกทันที จึงต้องแยกว่ารัน Node สำเร็จ, ส่ง Request แล้ว, API ตอบรับ, ได้ Post ID และเปิดตรวจโพสต์ได้จริงหรือไม่. หาก API รับคำขอแล้ว n8n หลุดก่อนรับ Response ระบบอาจคิดว่าล้มเหลวทั้งที่มีโพสต์เกิดขึ้น. การ Retry ทันทีโดยไม่ตรวจอาจสร้างโพสต์ซ้ำ.

ออกแบบ Publish Key ให้ชัดเจน

ใช้ Key เชิงธุรกิจแบบ page_id:content_id:approved_revision และบังคับ Unique Constraint ในระบบคิว/ฐานข้อมูลเพื่อป้องกันสอง Worker Claim งานเดียวกัน. นี่เป็น รูปแบบควบคุมภายในที่เสนอ ไม่ใช่การอ้างว่า Meta รองรับ HTTP Header Idempotency-Key บนทุก Endpoint. เมื่อ Revision เปลี่ยน ควรตรวจด้วยคนก่อนว่าต้องการเผยแพร่ฉบับใหม่หรือแก้ของเดิม.

Error Matrix สำหรับผู้ดูแล

Not approved: บันทึก blocked ไม่เรียก API. Invalid Token: แจ้งเจ้าของ Credentials ไม่ Retry แบบเดิม. Rate Limit: พิจารณา Backoff ตามข้อกำหนดที่ยืนยันแล้ว. Timeout After Send: บันทึก unknown และตรวจผลปลายทางก่อน. Post ID Save Failed: ห้ามสมมติว่าไม่ได้โพสต์. Concurrent Claim: หยุดงานที่ซ้ำและแจ้งตรวจ Lock. ตั้งกฎว่าสถานะ unknown ห้ามเปลี่ยนเป็น failed โดยอัตโนมัติเมื่อยังไม่มีหลักฐาน.

บันทึก Event Log แบบไม่เปิดเผยข้อมูล

Log ควรมี content_id, revision, page_id, execution_id, attempt, last_checked_at, error_class, post_id และ state. ไม่ควรเก็บ Bearer Token, Password, Full Request Header หรือข้อมูลลูกค้าในช่องแจ้ง Error. ถ้าไม่ต้องแสดง Caption ทั้งหมดให้ใช้ Content Hash และเก็บฉบับจริงในแหล่งที่มีสิทธิ์เข้าถึงเฉพาะ.

ขั้นตอน Recovery หลัง Timeout

(1) หยุด Retry อัตโนมัติ (2) ตรวจ Execution และ Request ID ที่ไม่ใช่ความลับ (3) ตรวจ Facebook Page ด้วยสิทธิ์ของทีมว่ามีโพสต์ตามรายการหรือไม่ (4) หากพบให้บันทึก Post ID (5) หากยืนยันว่าไม่ได้โพสต์และสิทธิ์ยังถูกต้อง จึงให้คนอนุมัติ Retry (6) ถ้าตรวจไม่ได้ให้คง unknown และแจ้งผู้รับผิดชอบ. อย่าปล่อยให้งานค้างถูกส่งซ้ำทุกครั้งที่ Schedule Trigger ทำงาน.

ระบบแจ้งเตือนและแผนหยุดฉุกเฉิน

ใช้ n8n Execution History และ Error Workflow ส่งแจ้ง Step, Content ID และ Error Class ให้ทีมดูแล โดยจำกัดข้อมูลที่ส่งออก. เพิ่มวิธี Pause Publishing Queue, Rotate Credentials, ตรวจโพสต์ที่เผยแพร่ผิด และมอบหมายผู้มีสิทธิ์แก้ไขหรือถอดโพสต์. ต้องรู้ว่าเมื่อคนรับผิดชอบลาหรือเปลี่ยนงาน ใครรับช่วงต่อได้.

Runbook เมื่อสถานะของโพสต์ไม่แน่นอน

ทีมไม่ควรมีเพียงปุ่ม Retry แต่ควรมีขั้นตอนปิดเหตุการณ์ด้วยหลักฐาน:

1. รับ Alert พร้อม `content_id`, `revision`, `page_id` และเวลาที่ระบบส่งคำขอ โดยไม่แนบ Token หรือข้อมูลลับ
2. ตรวจ n8n Execution เพื่อแยกว่า Request ยังไม่ถูกส่ง หรือส่งแล้วแต่ไม่มี Response
3. หากส่งแล้ว ให้เข้าตรวจเพจ/รายการโพสต์ผ่านบัญชีที่ได้รับสิทธิ์ ไม่เดาว่าการ Timeout เท่ากับโพสต์ล้มเหลว
4. หากพบโพสต์จริง บันทึก Post ID และปิดเหตุการณ์เป็น Published/Verified ตามหลักฐาน
5. หากไม่พบและพิสูจน์ว่าไม่เคย Publish ได้ จึงให้ผู้มีสิทธิ์พิจารณา Retry เฉพาะคำขอที่จำเป็น ไม่ Replay Workflow ทั้งชุดแบบไม่ตรวจ
6. หากยังพิสูจน์ไม่ได้ ให้คง `unknown` และหยุดคิวนั้นจนกว่าจะมีคนตรวจเสร็จ

Idempotency แบบไหนที่ยังไม่พอ

ตัวอย่าง Dry Run ใช้ JavaScript `Set` ป้องกัน `page_id:content_id:revision` ซ้ำ ภายในหนึ่ง Batch เดียว; ถ้า Schedule Trigger เปิด Workflow Run ใหม่ ค่า `Set` จะเริ่มใหม่และไม่รู้ว่ารอบก่อนส่งอะไรไปแล้ว. Production ต้องมี Durable Store ซึ่งบังคับ Unique Key/Atomic Claim ได้ และมีขั้นตอน Reconciliation กับ Post ID จริง. นี่เป็นการออกแบบระบบฝั่งเรา ไม่ใช่ การยืนยันว่า Meta API มี Idempotency Header สำหรับทุก Endpoint.

สถานะ	คำสั่ง Retry ที่ปลอดภัย
`blocked`	ไม่ Retry จนกว่า Approval/ข้อมูลครบ
`failed_auth`	แก้ Credential แล้วทดสอบการอ่านก่อน
`retryable`	ตรวจ Rate Limit และ Backoff จากคำตอบบริการ
`unknown`	ห้าม Retry จนกว่าจะตรวจปลายทาง
`published`	ไม่ส่งอีก; เก็บ Post ID/Log

ทดสอบเจ็ดสถานการณ์ก่อนรับงาน

Draft ไม่โพสต์; Revision ไม่ตรงไม่โพสต์; ยังไม่ถึงเวลาไม่โพสต์; Token ผิดไม่ Retry รัว; Timeout แล้วต้อง Unknown; สอง Worker Claim เดียวกันต้องได้เพียงหนึ่ง; Media URL ผิดต้องหยุด. ทดสอบบน Dry Run ก่อน และแยก Evidence Test Page ของ Meta จริงออกจากตัวอย่างทางเอกสาร.

อ่านต่อ

ทบทวน ภาพรวม Facebook Automation, สิทธิ์ Facebook Graph API และ Google Sheets Content Calendar. หากต้องเชื่อมงานขายให้ดู ระบบรับลีดด้วย n8n ซึ่งเป็นอีก Workflow ไม่ใช่การโพสต์เพจ.

แหล่งอ้างอิงและขอบเขตการตรวจ

ข้อมูล n8n ตรวจวันที่ 3 พฤศจิกายน 2026: Facebook Graph API Node, Schedule Trigger, Executions และ Gmail Approval. หากจะเผยแพร่บน Facebook Page ให้ตรวจ Meta Pages API สำหรับ Permissions, App Review, Media Endpoints และ Graph API Version กับบัญชีผู้พัฒนาที่ได้รับสิทธิ์จริงก่อน Deploy. บทความนี้ไม่ได้ใช้บัญชี Page เพื่อโพสต์จริง.