How to monitor published, reviewing, and offline posts

Once a post has been sent out, the hard part is often no longer “can I publish it?” but what state is it actually in now? Many teams treat a success toast, a redirect, or an API response as the end of the story. In real cross-posting workflows, that is not enough. The meaningful states are often reviewing, published, offline, draft, and sometimes unknown when the platform does not give a reliable answer yet.

That is why OmniGoAI's OmniPost treats “publishing” and “checking what happened after publishing” as two separate jobs. The first step pushes content out. The second tells you whether the post is truly live, still under review, already removed, or never left draft state. Without publish-status monitoring, teams routinely mistake a submission event for a durable publishing outcome.

If you are building your own distribution workflow, it also helps to read Choosing between OmniPost CLI, MCP, and HTTP and An autonomous daily content pipeline with AI agents. This article focuses on a narrower but operationally critical question: after you publish, how do you verify whether a post is reviewing, published, offline, or still just a draft?

The short answer: a publish result proves a submission happened, not that the post is still live

There are three practical rules to remember:

1. a successful publish call means the platform accepted a submission attempt, not that the content is permanently visible;
2. reviewing, published, offline, draft, and unknown are operationally different states and should never be merged into one “success” bucket;
3. status checks should be a standard step in the workflow, not a manual investigation only when something feels wrong.

This matters even more on platforms with moderation or delayed review. A post can be accepted first and judged later. A link may exist while the platform still marks the article as reviewing. Another post may look successful at first and later fall into an offline state. If you only store the initial publish result, what you have is an action log, not a trustworthy survival signal.

Which statuses actually matter in OmniPost?

OmniPost's publish-status command normalizes different platform behaviors into a small set of useful states.

1. reviewing

This means the post has been submitted successfully, but the platform has not finalized its decision yet.

Operationally, that usually means:

• do not publish the same post again right away;
• record it as sent, but not yet fully settled;
• check again later to see whether it becomes published, rejected, or offline.

This is especially common on platforms where content goes through post-submission moderation. In that case, reviewing is not a failure, but it is also not the same as stable publication.

2. published

This is the healthy target state. It means the platform currently recognizes the post as publicly available.

At that point you can usually:

• record the public URL;
• start collecting views, likes, comments, or other metrics;
• include the post in distribution and reporting totals.

Still, published should not always be treated as permanent. On some platforms, content can later be limited, hidden, or taken down. That is why status checks are useful even after the initial publish succeeds.

3. offline

This is one of the most important states to monitor because it is easy to miss if you only keep the original publish result.

In practice, it usually means:

• the post was successfully created at some point;
• but it is no longer available as a live public post now;
• it should no longer be counted as an active distribution outcome.

If your spreadsheet still says “published” while the platform now reports offline, your reporting and your actual content footprint have diverged.

4. draft

This state appears in at least two common situations:

1. you intentionally used draft mode;
2. a publish attempt failed, but the platform still kept a draft.

That second case matters more than many teams realize. A failed publish does not always mean “nothing was saved.” Sometimes the right recovery path is to continue from the existing draft instead of creating another duplicate attempt.

5. unknown

unknown does not automatically mean failure. It means the available platform signal is not strong enough to classify the post reliably yet.

That is why you should combine it with other evidence such as:

• whether a public post URL already exists;
• whether metrics can be collected later;
• whether a second status check converges to a clearer state;
• whether the platform returned a real post page or only an editor-like view.

In other words, unknown means “observe carefully,” not “assume dead.”

Why does relying on the initial publish result create bad decisions?

Because the initial publish result answers a narrower question: was the submission attempt accepted? It does not fully answer: what is the post's real state now?

Here are a few common mistakes:

1. Counting reviewing posts as fully live content.
2. Continuing to count offline posts as active channel wins.
3. Treating leftover drafts from failed publishes as completed publication.
4. Treating unknown as failure and publishing duplicates unnecessarily.

Once those mistakes enter your workflow, they start contaminating later steps too: reporting, retries, republishing decisions, and account health judgments all get worse.

The most direct OmniPost command for status checks

The simplest path is:

D:\soft\omnipost\omnipost.cmd publish-status zhihu --recordId <recordId>

You can also query by platform post ID:

D:\soft\omnipost\omnipost.cmd publish-status juejin --postId <postId>

And if title lookup is the only thing you have, you can query by title:

D:\soft\omnipost\omnipost.cmd publish-status csdn --title "How to monitor published, reviewing, and offline posts"

Of those three, recordId is usually the safest input because it points to one exact OmniPost record. It also keeps your local history cleaner because the latest status can be written back to that same record.

A more reliable workflow: list posts first, then check publish-status

In practice, the safer workflow is two-step.

Step 1: list recent records

D:\soft\omnipost\omnipost.cmd posts --limit 20 --platform juejin

This helps you confirm:

• the recordId;
• the postId;
• the current stage;
• the stored postUrl;
• any previously known reviewStatus.

Step 2: check one exact record

D:\soft\omnipost\omnipost.cmd publish-status juejin --recordId post_1786147555801_3

That approach is safer because:

1. you reduce the chance of checking the wrong article;
2. you can distinguish “this was always a draft” from “this changed after publication”;
3. you can plug the same logic into daily monitoring or post-publish review jobs.

When should status checks become a standard operating step?

1. On the same day as formal publication

This is the minimum useful layer. The goal is to separate:

• posts still in reviewing;
• posts now clearly published;
• posts that drifted into offline or remain unknown.

If your team does real multi-platform publishing, this is worth standardizing.

2. On platforms with moderation or delayed review

Whenever a platform regularly accepts content before reaching a final moderation decision, status checks are not optional. Without them, you cannot tell the difference between “submitted and waiting” and “never truly made it live.”

3. Before weekly reporting or attribution reviews

A report that says “we published 12 posts this week” is often too shallow. A more useful one asks:

• how many are actually published now;
• how many are still reviewing;
• how many became offline later;
• which platform shows unusual levels of unknown or takedowns.

That kind of reporting can improve future channel choices and editorial patterns.

4. After rate limits, dedup hits, or account health warnings

Once an account has shown signs of rate limiting, login trouble, or moderation sensitivity, the main question is no longer just “can we submit?” but “does the platform keep the post alive after submission?”

How is publish-status different from metrics?

Teams often mix metrics and publish-status, but they answer different questions.

• publish-status asks: what state is this post in right now?
• metrics asks: for a post that exists, how much engagement has it received?

The order matters. First confirm that the post is still alive, then measure how it performs.

If a post is already offline, good historical metrics do not mean it is still contributing reach. If a post is still reviewing, early metric interpretation may be premature.

A practical automation rule

If you want to turn this into a scheduled monitoring job, a simple rule set works well:

1. reviewing → observe again later;
2. published → include it in metric collection;
3. offline or rejected → flag the run and inspect compliance or platform fit;
4. draft → determine whether it was intentional or left behind by a failed publish;
5. unknown → make a conservative judgment using postUrl, later metrics, and a second status pass.

The value of this rule is that it turns post-publish follow-up from tribal knowledge into repeatable operational logic.

Why is this especially important for cross-posting tools?

Because the hard part of multi-platform distribution is not only sending one post to many destinations. It is that each platform evolves the post into a different state afterward.

The same article can easily end up in a mixed state such as:

• Zhihu: published
• Juejin: reviewing
• CSDN: unknown
• CNBlogs: published

Without a unified check layer, your team ends up manually opening creator dashboards one by one. OmniPost does not remove platform differences. What it does is give you one consistent way to observe those differences and act on them.

FAQ

If publish already returned success, why check again?

Because publish success usually proves a submission attempt was accepted, not that the post is still publicly live right now. Review, takedown, and draft retention can all happen after the initial success.

Does unknown mean the post failed?

No. It means the available evidence is not yet strong enough to classify the post confidently. Use the URL, later metrics, and a second status check before making a republish decision.

Should I republish a reviewing post?

Usually no. A reviewing state means the platform is already processing the submission. Republishing too early can create duplicates or trigger dedup logic.

Does draft always mean I intentionally saved a draft?

Not always. Some failed publish attempts still leave a draft behind, so you need to compare the status with the original publish record.

When is it worth turning status checks into a scheduled task?

As soon as you are doing formal multi-platform publishing, or once you have seen review delays, takedowns, rate limits, or login issues. For content operations, this often matters more than having one more publish button.

If you want to connect publishing, status checks, metric collection, and cross-posting in one workflow, try OmniGoAI's OmniPost: https://omnigoai.com/en/download/omnipost/ . It is built not only to send content out, but also to help you observe what happens after publication and act on that information.