IST शेड्यूल बैच रीट्राय वर्कशीट

एक ही बैच में पाँच सोशल पोस्ट शेड्यूल किए गए। डैशबोर्ड पर दो published, एक failed और दो अभी scheduled दिख रहे हैं। क्या पूरे बैच को फिर से चलाना चाहिए? नहीं। पहले हर चैनल की अपनी प्रमाण-पंक्ति बनाइए और उसी content, job तथा provider ID को सार्वजनिक मूल पोस्ट से मिलाइए।

भारत में यह जाँच करते समय IST का आधे घंटे वाला UTC अंतर और आधी रात की तारीख बदलना विशेष रूप से महत्वपूर्ण है। 00:05 IST को पिछली UTC तारीख के 18:35Z से मिलाना पड़ सकता है। केवल घड़ी देखकर तुलना करने पर सही job भी गायब या देर से चला हुआ लग सकता है।

छोटा उत्तर: बैच नहीं, हर गंतव्य को अलग जाँचें

सुरक्षित रीट्राय का नियम है:

हर चैनल के लिए एक अलग पंक्ति रखें।
content ID, publish job ID और provider post ID को अलग कॉलम में लिखें।
IST समय के साथ पूरा ISO/UTC समय भी रखें।
permalink मिले तो उसी सार्वजनिक मूल पोस्ट को खोलें।
परिणाम अस्पष्ट हो तो नया content object न बनाएँ।

एक बैच का सारांश 3/5 published उपयोगी है, लेकिन उससे यह तय नहीं होता कि किस गंतव्य को रीट्राय करना सुरक्षित है। निर्णय हमेशा पंक्ति स्तर पर होना चाहिए।

तीन ID एक ही बात नहीं बताते

Content ID

Content ID बताता है कि किस स्वीकृत सामग्री और चैनल निर्देश को ट्रैक किया जा रहा है। इसे बदलकर नया content बनाने से पुरानी कोशिश का इतिहास टूट सकता है।

Job ID

Job ID प्रकाशन की किसी विशेष कोशिश या शेड्यूल किए गए काम को पहचानता है। एक content के साथ एक या अधिक job रिकॉर्ड हो सकते हैं, इसलिए नवीनतम job को पुराने job से न मिलाएँ।

Provider post ID या permalink

यह सबसे मजबूत संकेत है कि सोशल नेटवर्क के पास कोई सार्वजनिक object हो सकता है। Provider ID या permalink मौजूद हो तो blind retry से पहले उसी object को खोलना आवश्यक है।

इन तीनों को एक कॉलम में ID लिख देना पर्याप्त नहीं है। अलग पहचान ही duplicate recovery को रोकती है।

IST और UTC को सही तरह मिलाएँ

IST पूरे वर्ष UTC से +05:30 आगे रहता है। फिर भी तारीख बदलने के कारण दृश्य तुलना कठिन हो सकती है।

उदाहरण के लिए:

भारत का शेड्यूल समय	समान UTC समय	ध्यान देने वाली बात
15 अगस्त 2026, 23:50 IST	15 अगस्त, 18:20Z	वही तारीख
16 अगस्त 2026, 00:05 IST	15 अगस्त, 18:35Z	UTC में पिछली तारीख
16 अगस्त 2026, 00:20 IST	15 अगस्त, 18:50Z	बैच क्रम UTC में भी स्पष्ट रखें

वर्कशीट में केवल 00:05 न लिखें। तारीख, Asia/Kolkata या IST, और UTC timestamp साथ रखें। इससे आधी रात के बाद वाला post गलत दिन में खोजने की समस्या घटती है।

प्रति-चैनल सुरक्षित रीट्राय वर्कशीट

हर गंतव्य के लिए यह पंक्ति भरें:

channel/account:
scheduled_at_ist:
scheduled_at_utc:
content_id:
job_id:
latest_state:
provider_post_id:
provider_permalink:
public_original_result:
text_media_link_result:
observed_at:
next_action:

public_original_result में केवल सही, आंशिक, नहीं मिला या अभी जाँचा नहीं लिखें। हर निष्कर्ष को देखा गया, अनुमान या अज्ञात के रूप में अलग रखें। Password, access token, signed upload URL, private prompt या ग्राहक डेटा इस वर्कशीट में न रखें।

उदाहरण: एक IST बैच, तीन अलग निर्णय

यह एक समझाने वाला उदाहरण है, किसी वास्तविक प्रदर्शन या ट्रैफ़िक का दावा नहीं।

पंक्ति	अंतिम प्रमाण	सुरक्षित निर्णय
Instagram, 23:50 IST	`published`, provider ID और सही सार्वजनिक मूल	पुष्टि करें; रीट्राय नहीं
Facebook, 00:05 IST	`scheduled`, वही job ID, समय सीमा अभी बाकी	प्रतीक्षा करें
Threads, 00:20 IST	`failed`, लेकिन provider permalink मौजूद	पहले मूल पोस्ट से मिलान करें

अगर Threads का मूल post सही मिलता है, तो failed state के बावजूद उसे दोबारा प्रकाशित नहीं करना चाहिए। अगर root मौजूद है पर reply गायब है, तो पूरे root को फिर से भेजना सुरक्षित समाधान नहीं है; केवल गायब हिस्से की स्थिति जाँचें।

सार्वजनिक मूल पोस्ट में क्या जाँचें

Dashboard और API state के बाद provider original खोलें। कम से कम ये बिंदु देखें:

सही सार्वजनिक account;
स्वीकृत text;
अपेक्षित image या video;
root और reply की पूरी संरचना;
URL text और वास्तविक clickable link;
duplicate provider object की अनुपस्थिति।

एक permalink केवल यह सिद्ध करता है कि कोई स्थान उपलब्ध है। वह अपने आप यह सिद्ध नहीं करता कि text, media, reply और link सभी सही हैं। इसी तरह published job state सार्वजनिक rendering की पूरी जाँच नहीं है।

अस्पष्ट परिणाम में चार सुरक्षित वर्ग

1. पुष्टि की गई

Content, job, provider ID, account, समय और सार्वजनिक मूल पोस्ट आपस में मेल खाते हैं। पंक्ति बंद करें और रीट्राय न करें।

2. प्रतीक्षा करें

Job अभी scheduled या publishing है, stable ID मौजूद है और अपेक्षित समय सीमा समाप्त नहीं हुई। अगला जाँच समय लिखें।

3. रीट्राय से पहले मिलान करें

State failed या असंगत है, लेकिन provider ID, permalink या संभावित सार्वजनिक object मौजूद है। उसी object को खोलें और केवल कमी वाले हिस्से को अलग करें।

4. रोकें: प्रमाण अज्ञात

Stable ID या भरोसेमंद सार्वजनिक परिणाम नहीं है। Automatic recovery रोकें। अज्ञात को अपनी सुविधा से failed या「कुछ प्रकाशित नहीं हुआ」न मानें।

60 सेकंड की प्रक्रिया

बैच से हर channel/account की अलग पंक्ति बनाएँ।
IST और UTC दोनों समय लिखें।
उसी content ID और job ID का नवीनतम state पढ़ें।
Provider ID या permalink मिले तो सार्वजनिक मूल खोलें।
Text, media, root/reply और clickable link को अलग जाँचें।
चार परिणामों में से एक चुनें और केवल आवश्यक अगला कदम लें।

मुफ़्त सोशल प्रकाशन प्रमाण चेकर खोलें

चेकर browser में स्थानीय रूप से चलता है। Login आवश्यक नहीं है और भरी गई जानकारी भेजी या संग्रहीत नहीं होती। यह किसी सोशल account से नहीं जुड़ता, content नहीं बनाता और publication request नहीं भेजता।

अक्सर पूछे जाने वाले प्रश्न

क्या पूरे batch को एक साथ retry करना कभी सुरक्षित है?

केवल तब जब हर destination की पंक्ति से यह प्रमाणित हो कि कोई provider object नहीं बना और वही सुधार सभी पर लागू है। आंशिक सफलता में पूरे batch को दोहराना duplicate बना सकता है।

`failed` दिखे तो provider मूल क्यों खोलें?

क्योंकि request या response के अलग चरण में error हो सकता है। Provider ID या permalink मौजूद होने पर सार्वजनिक object पहले ही बना हो सकता है। कारण का अनुमान लगाए बिना मूल परिणाम देखें।

IST में आधी रात का post कहाँ खोजें?

पहले पूरे IST timestamp को UTC में बदलें। 00:05 IST अक्सर पिछली UTC तारीख पर होगा। Account और समय की छोटी window साथ इस्तेमाल करें।

क्या यह चेकर AI से caption लिखता है?

नहीं। यह उपलब्ध प्रमाण के आधार पर अगला कदम वर्गीकृत करने वाला deterministic tool है। यह copy नहीं बनाता और data किसी AI model को नहीं भेजता।

ANKK की भूमिका

मैं Minho Jung हूँ और ANKK का संचालन करता हूँ। ANKK में built-in AI writer नहीं है और यह AI content generator नहीं है। यह लोगों, बाहरी AI tools या scripts से तैयार content को कई सोशल चैनलों की scheduling, terminal state और provider-original verification से जोड़ता है।

मुफ़्त चेकर retry से पहले निर्णय लेने का स्वतंत्र साधन है। लगातार संचालन में ANKK content, job और हर channel के सार्वजनिक परिणाम को एक ही publishing flow में जोड़ने में मदद करता है।

ANKK की scheduling, state और provider-original प्रक्रिया देखें

प्रकाशन अनुबंध

Body H1: 0
Clean checker link: 1
Unique HI campaign CTA: 1
Create, update और publish: अधिकतम 1 बार प्रत्येक
Retry, ambiguity के बाद edit, IndexNow, synthetic click और paid distribution: 0