A post is scheduled for 00:30 WIB, while the dashboard records the job under the previous UTC date. On the public account, the root post is visible, replies are missing, the image appears, and the URL renders only as plain text. Did the post fail, and should you resend it?
Not necessarily. Posts scheduled just after midnight are easy to misclassify because four types of evidence get mixed together: time, internal status, post structure, and the public result. Match the same instant first, then inspect each component in the provider original before choosing an action.
This guide uses one evidence sheet to decide whether to confirm, wait, reconcile, or hold.
Why can 00:30 WIB appear under a different UTC date?
WIB is UTC+7. This means that August 15 at 00.30 WIB is August 14 at 17.30 UTC. Both timestamps point to the same instant even though the calendar dates are different.
A common mistake is comparing only the hour numbers or only the date. The operator then considers the job to be one day late, even though the dashboard and local calendar use a different time zone. Before assessing the delay, store the following three values in one row:
| Value | Example | Uses |
|---|---|---|
| Approved time | 2026-08-15 00:30 WIB |
Operational promises to operators |
| System saved time | 2026-08-14T17:30:00Z |
Neutral instant to compare logs |
| Public observation time | 2026-08-15 00:38 WIB |
When will the provider's results actually be checked |
Time zone conversions are not proof of publication. It just makes sure you are assessing the right job in the right window.
Five evidence fields for each destination
Create one row per destination account, not one row for the entire batch. Fill in the following five columns:
- Public channels and accounts — for example Threads
@merek, not just “Threads”. - Scheduled instant — local time, time zone, and UTC equivalent.
- Content ID or job ID — stable identity to follow the same operation.
- Last status and time of observation — exact value such as
scheduled,publishing,published, orfailed. - Original post URLs and component results — root, reply, media, and links are checked separately.
Don't enter tokens, passwords, signed upload URLs, private prompts, or customer data. This sheet only requires operational metadata and what is visible on the public surface.
Audit root, reply, media, and links separately
One permalink does not prove that the entire post structure is correct. Use the following completeness matrix on the provider original post:
| Components | Observation questions | Logged values |
|---|---|---|
| Root | Account, text, and provider ID match? | true / false / unknown |
| Reply | The reply is there, in the correct order, and attached to the right root? | complete / missing / wrong destination |
| Media | The image or video is actually rendered, not just a placeholder? | displayed / failed / still processing |
| Link | Is there a clickable anchor whose href goes to an approved destination? | click / text only / wrong destination |
For example, a public root with missing replies is partial publication, not a complete failure. Resending root to correct reply can create two roots. Likewise, the URL seen in the caption may not necessarily be the click path; note the text and anchor as two different pieces of evidence.
Four actions from the evidence sheet
After five columns and four components have been checked, select exactly one of the following actions.
1. Confirm
Select confirm when account, instance, ID, terminal status, and all public components match. Save the permalink and observation time, then close the job. Don't resubmit just to get a cleaner API response.
2. Wait and check again
Select wait while the job is still scheduled or publishing, a stable ID is available, and the observations are still within a reasonable window. Set a time for the next inspection. Waiting indefinitely is not control; waiting by ID and deadline is an operational decision.
3. Reconcile before retry
Select reconcile when the internal status shows an error but the root, reply, media, or provider object may already exist. Maintain all IDs, check accounts over a normalized time window, then determine which components are truly incomplete. Do not repeat batches where other objectives are correct.
4. Hold as unknown
Select hold when there is no stable ID and the public results are inconclusive. Tidak diketahui is not a synonym for gagal. Changing it to fail without proof can allow a retry that creates a second object.
Example of audit after date change
For example, one thread is scheduled at 00.30 WIB:
account: @brand
scheduled_local: 2026-08-15 00:30 WIB
scheduled_utc: 2026-08-14T17:30:00Z
content_or_job_id: job_4821
last_state: failed at 00:32 WIB
provider_original: available
root: correct
reply: missing
media: displayed
link: text only, no anchor
observed_at: 00:38 WIBThe right decision is not “resend everything”. These are partial results that need to be reconciled. The root already exists, so retrying the root risks creating a duplicate. Reply and carrier links need to be handled as separate components according to provider capabilities and channel policies.
Use the checker as a classification tool, not provider evidence
Open Social Publishing Proof Checker for free
The checker runs locally in the browser, does not require login, and does not send or save entered values. It helps turn five facts into four action options. Checker does not contact social networks and cannot prove that posts are truly public; The provider original posting remains the final source of evidence.
FAQs
Does a different UTC date mean the schedule is wrong?
Not always. Change both timestamps to the same instant. 00.30 WIB is the same as 17.30 UTC on the previous date. The schedule is incorrect only if the instant is different from the approved one.
If root already exists but the reply is missing, is the status successful?
Note as partial publication. Don't call the entire thread successful, but don't repost a root that is already public. Reconcile replies separately.
Is the visible URL definitely clickable?
No. Check whether the provider page renders the anchor and whether the href decodes to the approved destination. URL text without an anchor is not a click carrier.
Does the checker create or schedule posts?
No. The checker simply groups the evidence you enter. It doesn't connect to social accounts, doesn't create content, and doesn't publish anything.
How ANKK fits into this workflow
I'm Minho Jung, ANKK operator. ANKK is not a content generator with built-in AI. ANKK connects content prepared by humans, external AI, or scripts to scheduling, per-channel status, and verification of providers' original posts.
The free checker is a stand-alone decision tool. For repeated operations, ANKK helps keep content ID, job, terminal status, and provider URL in the same flow.