A post is scheduled for 00:15 in Vietnam, while the log records 17:15 UTC on the previous date. After the scheduled time, the dashboard shows failed, but nobody has checked the public account. Should you create a new scheduled post immediately?
No. First confirm that you are looking at the same instant, the same content and job IDs, and the correct provider account. A date change between ICT and UTC can make the correct job look missing. Retrying against the wrong date may create a duplicate even if the first request already reached the provider.
The procedure below helps operators choose among four actions: confirm, wait, reconcile before retrying, or hold as unknown.
ICT and UTC may have different dates but the same time
Vietnam time uses ICT, which is UTC+7 and does not change with the seasons. So:
2026-08-15 00:15 ICT
= 2026-08-14T17:15:00ZThe two values are different calendar dates but are the same time. When checking a job past 0 hours, don't compare the number of days or hours separately. Save local time, timezone, and standard UTC values as well.
| Time field | Example | Purpose |
|---|---|---|
scheduled_at_local |
2026-08-15 00:15 ICT |
Article approved by the operator |
scheduled_at_utc |
2026-08-14T17:15:00Z |
Public key to compare logs between systems |
observed_at |
2026-08-15 00:23 ICT |
When the original post is checked |
If these three fields are not separated, an on-time job could be labeled one day late. However, changing the timezone only fixes the comparison; it does not prove that the article has been published.
Track the existing ID chain instead of creating a new request
Each stage can generate a different identifier. Put them on the same line to see where the evidence stops:
- content ID — saved content object;
- job ID — the scheduling or publishing job is being processed;
- provider post ID — object that the social network received or created;
- provider-original URL — public surface for viewers to inspect.
The existence of a Content ID does not mean the job has run. The existence of a Job ID does not mean the provider created the post. Provider post ID is more powerful, but you still need to open the original post to check the account, content, and visibility.
Once you have the job ID, read the correct job again. Creating new content or jobs just to “see if they work” loses the relationship between the original request and the public result.
One line of evidence per target account
Don't combine a bunch of channels into one state. For each account, save at least:
channel/account:
scheduled_at_local:
scheduled_at_utc:
content_id:
job_id:
last_state + observed_at:
provider_post_id:
provider_original_url:
public_outcome:Record only safe operating data. Do not save passwords, access tokens, signed upload URLs, privacy prompts, or customer data in the incident panel.
The provider original must be checked for each component
A public URL does not prove the entire article is correct. Open the provider's page and write down each component:
| Ingredients | Questions to answer | Suggested value |
|---|---|---|
| Account | Is the article located on the approved profile/page? | true / false / unclear |
| Root | Is the text and provider ID of the original post correct? | true / missing / false |
| Reply | Reply exists, in the correct order and at the correct root? | complete / missing / wrong destination |
| Media | Completely rendered photo or video? | show / processing / error |
| Link | Is there a clickable anchor with the correct href? |
clickable / just text / wrong destination |
The root is public but the missing reply is a partial result, not a complete error. The URL is visible in the caption but has no anchor and is not a complete click path. Separating components helps you deal with only the missing part instead of reposting the correct part.
Four decisions after comparison
1. Confirmation
Select confirm when scheduled_at, ID string, last status and original post match. Account, root/reply, media and link are all correct. Save the URL with the observation time and then close the job; Do not retry to change an outdated API response.
2. Wait and set the next check time
Select wait while the job is scheduled or publishing, has a stable ID and is still within reasonable processing range. Specify the next check date. Waiting for a time limit is a controlled action; Constantly refreshing or creating new jobs is not evidence.
3. Reconcile before retrying
Select reconcile when the system reports an error but the provider post ID, URL, or post on a public account may already exist. Compare the correct ICT/UTC converted time period, keep the old ID intact, and determine which components are actually missing. If three channels are correct and one channel is unclear, do not rerun the whole batch.
4. Keep the status unknown
Select unknown when there is no stable ID and the results cannot be publicly confirmed. Chưa rõ is not synonymous with failed. Stop automatic retry and find the last point with evidence before allowing new requests.
Real-life example for day shift
A small group in Ho Chi Minh City reviews the article at 23:50 ICT and sets the schedule for 00:15 ICT. The system saves 2026-08-14T17:15:00Z. At 00:17 ICT, job moved to failed; at 00:23 ICT, root appeared on the correct account but the reply contained a link that was not available.
Correct conclusion:
- timezone and date are not wrong: the two timezones are the same time;
- job needs to be kept because the ID associated with the root is public;
- the result is partial, not total failure;
- retrying the entire thread has the risk of creating duplicate roots;
- the next step is to compare the missing replies according to the channel's capabilities.
This example shows scheduled_at, the ID, and the original post answering three different questions. Only by placing them side by side will the operator know which part has been completed.
Use checker to classify, do not change the provider original
Open Social Publishing Proof Checker for free
Checker runs locally in the browser, does not require a login, and does not send or save the data you enter. It helps organize the five pieces of evidence into four actions. Checker does not connect to social networks and does not verify published posts; provider-original URL remains the final source of testing.
Frequently asked questions
Does ICT change seasonally like some other time zones?
No. ICT in Vietnam is UTC+7 all year round. However, always save the timezone with scheduled_at so that the international log and the local interface are compared at the same time.
What should I do if I have a job ID but no provider post ID?
Track the job ID itself to its final status or set inspection due date. Don't create a new job just because the provider ID doesn't appear right away.
The root is public but the reply is missing. Is that a success?
Please write as partially published. Keep the correct root and compare the reply separately; Don't resubmit the entire thread.
If a URL appears as text, can viewers always click it?
No. Check the anchor and href on the original post. A URL string without an anchor is just text, not a confirmed carrier click.
Does Checker create content or post?
No. Checker only sorts evidence in the browser. It doesn't connect accounts, doesn't create content, doesn't schedule, and doesn't publish.
How ANKK fits into this workflow
I'm Minho Jung, the operator of ANKK. ANKK does not have a built-in AI content generator. ANKK connects content prepared by humans, external AI or scripts with posting schedules, channel status and verification of the original post by the provider.
Free Checker is an independent decision tool. For repeat operations, ANKK helps keep the content ID, job ID, final status, and provider-original URL in the same tracking stream.