Five social posts are scheduled in one batch. The dashboard shows two as published, one as failed, and two as scheduled. Should you rerun the entire batch? No. Create a separate evidence row for each channel and match its content, job, and provider IDs to the provider original.
The five-and-a-half-hour offset between IST and UTC, together with the date change around midnight, makes this especially important in India. For example, 00:05 IST corresponds to 18:35Z on the previous UTC date. If you compare only the displayed clock time, the correct job can look missing or delayed.
Short answer: check every destination separately, not the whole batch
The rule of safe retry is:
- Have a separate row for each channel.
- Write content ID, publish job ID and provider post ID in separate columns.
- Keep complete ISO/UTC time along with IST time.
- If you find the permalink, open the same public original post.
- Do not create a new content object if the results are unclear.
A batch summary 3/5 published is useful, but it does not determine which destination is safe to retry. Decisions should always be at the line level.
Three IDs do not tell the same thing
Content ID
Content ID specifies which approved content and channel directives are being tracked. Changing it and creating new content may break the history of the old effort.
Job ID
The Job ID identifies a particular publish attempt or scheduled job. There can be one or more job records associated with one content, so do not mix the latest job with an older job.
Provider post ID or permalink
This is the strongest indication that a social network may have a public object. If Provider ID or permalink is present then it is necessary to open the same object before blind retry.
It is not enough to write these three in one column ID. Distinct identification prevents duplicate recovery.
Match IST and UTC correctly
IST to UTC all year round+05:30Remains ahead. Yet visual comparisons may be difficult due to date changes.
For example:
| schedule time of india Same UTC time Point to note |---|---|---| | 15 August 2026, 23:50 IST | 15 August, 18:20Z | Same date | 16 August 2026, 00:05 IST | August 15, 18:35Z | Previous date in UTC | | 16 August 2026, 00:20 IST | 15 August, 18:50Z | Keep the batch order clear in UTC also.
Don't just type 00:05 in the worksheet. Include the date, Asia/Kolkata or IST, and the UTC timestamp. This reduces the problem of finding a post after midnight on the wrong day.
A safe retry worksheet for each channel
Fill in this line for each destination:
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:In public_original_result simply type Correct, partial, Not found or haven't checked yet. Separate each conclusion as seen, Estimate or unknown. Do not include passwords, access tokens, signed upload URLs, private prompts, or customer data in this worksheet.
Example: One IST batch, three different decisions
This is an illustrative example, not a claim for any actual performance or traffic.
| row | Final proof Safe decision
|---|---|---|
| Instagram, 23:50 IST | published, provider ID and correct public origin. confirm; No retry.
| Facebook, 00:05 IST | scheduled, same job ID, deadline still pending. wait
| Threads, 00:20 IST | failed, but provider permalink exists. First match the original post.
If the original post of Threads is found to be correct, then it should not be republished despite the failed state. If root exists but reply is missing, resending the entire root is not a safe solution; Just check the position of the missing part.
What to check in provider-original posts
Open provider original after Dashboard and API state. See at least these points:
- Correct public account;
- accepted text;
- desired image or video;
- Complete structure of root and reply;
- URL text and actual clickable link;
- Absence of duplicate provider object.
A permalink simply proves that a location is available. It does not automatically prove that the text, media, reply and link are all correct. Similarly published job state is not fully verified public rendering.
Four safe outcomes when the result is ambiguous
1. Confirmed
Content, job, provider ID, account, time, and public origin of the post match each other. Close the row and do not retry.
2. Wait
Job is currently scheduled or publishing, stable ID exists and not expired. Enter the next check time.
3. Match before retry
State failed or is inconsistent, but the provider ID, permalink or potentially public object exists. Open the same object and isolate only the missing part.
4. Stop: Evidence Unknown
There is no stable ID or trusted public results. Stop automatic recovery. Do not confuse unknown with failed or「nothing published」at your convenience.
A 60-second workflow
- Create a separate row for each channel/account from the batch.
- Write both IST and UTC time.
- Read the latest state of the same content ID and job ID.
- If you find Provider ID or permalink, open Public Origin.
- Check text, media, root/reply and clickable links separately.
- Choose one of the four outcomes and take only the necessary next steps.
Open Free Social Publishing Credential Checker
The checker runs locally in the browser. Login is not required and the information entered is not sent or stored. It does not connect to any social account, does not create content and does not send publication requests.
FAQ
Is it ever safe to retry the entire batch at once?
Only if each destination row confirms that no provider object was created and the same correction applies to all. Repeating the entire batch in case of partial success can create duplicates.
If failed is visible then why open the provider root?
Because errors may occur at different stages of the request or response. The public object may already be created if the Provider ID or permalink exists. See the original result without guessing the cause.
Where to find midnight post in IST?
First convert the entire IST timestamp to UTC. 00:05 IST will often be on the previous UTC date. Use with account and small window of time.
Does this checker write captions with AI?
No. This is a deterministic tool that takes the next step based on available evidence. It does not make copies and does not send the data to any AI model.
How ANKK fits into this workflow
I'm Minho Jung and run ANKK. ANKK does not have a built-in AI writer and is not an AI content generator. It connects content created by people, external AI tools or scripts with the scheduling, terminal state and provider-original verification of multiple social channels.
The free checker is a free tool to decide before retrying. In a consistent operation, ANKK helps connect content, jobs, and public results from each channel into a single publishing flow.
See ANKK's scheduling, state and provider-original process
Publishing checklist
- Body H1: 0
- Clean checker link: 1
- Unique HI campaign CTA: 1
- Create, update and publish: maximum 1 time each
- Retry, edit after ambiguity, IndexNow, synthetic click and paid distribution: 0