RSS į 66 socialinius tinklus: Facebook, Instagram, X, LinkedIn, Telegram ir kitus Blogas Partnerių programa Kontaktai
Short answer: PostRSS records every check of a source as a run, and each run lists the items it saw with a status: unprocessed, processed, failed, skipped, already posted, maximum posts per update reached or filtered. To find out why something was or was not posted, open the report of the target, look at the run at the right time, then open its items. The run shows how many items were seen and posted and gives a failure reason when the check itself failed, and each item shows its own status and, if it failed, the reason. Reading these two levels answers almost every question about missing posts.
Automation is only comfortable when you can see what it did. Most of the time PostRSS works quietly: a new article appears in your feed, and a post appears on your page a moment later. Sometimes something is different. A post you expected has not appeared. A post appeared twice on your list of activity. A feed that used to give three posts a day suddenly gives none. Before you change any settings, look at the evidence. PostRSS keeps a report for each target with the history of its checks, and for each check the list of items that were found and what happened to each one. This guide explains how to read that history, what each status means, the most common reasons behind a missing post and how to use the same data from your own scripts through the REST API. The statuses and fields below are the ones in the live API documentation.
The report has two levels. The first level is the run. Every time PostRSS checks a source, it records one run with the source, the date and time, whether the check succeeded, a failure reason if it did not, the number of items seen and the number of posts made. The second level is the item list of a run. For one run you can see every item that was found in the feed, with its title, its link, the message that was built for it, its image, its date and its status. Think of the run as the question did PostRSS manage to read the feed and the items as the question what did it decide for each article.
This separation tells you where to look. If runs are failing, the problem is the connection to the feed: the address, the server or the XML. If runs succeed but nothing is posted, the problem lies in the decisions made for the items: filters, limits, start date or duplicates. If items are marked as failed, the problem is the network where the post was to be published.
| Status | Meaning |
|---|---|
| Processed | The item was posted to the target |
| Already posted | The item was published earlier and is not posted again |
| Filtered | The keyword filter of the source excluded it; it is not posted and does not count towards limits |
| Maximum posts per update reached | The limit for this check was used up; the item can be considered again later |
| Skipped | The item was not posted for another reason, for example it was older than the date to post from |
| Failed | PostRSS tried to post and the attempt failed; the item carries a reason |
| Unprocessed | The item was seen but a decision has not been made yet |
Most of the time you will see processed and already posted. The others are clues. A long list of already posted items is normal, because feeds keep old articles for a while and PostRSS remembers which ones it has published.
Following the steps in this order solves most cases in a few minutes and avoids changing settings that were never the problem.
A failed run or a failed item carries a reason in plain text. The wording varies, but the causes fall into a few families. For a run, the feed may be unreachable because the server is down, a security rule blocks automated clients, the address redirects in a loop or the file is not valid XML. For an item, the network may reject the post because the account needs to be reconnected, the text or the image does not meet the rules of the network, or a temporary problem occurred on the platform. Some networks limit the length of a post or the size of an image, and some require that an account has the right permissions. When a reason mentions authorization, reconnect the account. When it mentions the feed, test the address from another network and validate it with the W3C Feed Validation Service. The guide on validating a feed before you auto-post shows a routine you can repeat.
If your source uses keyword filters, many items will show as filtered, and that is the filter doing its job. Filtered items are not posted, they do not count towards the maximum posts per update and they do not use your plan quota. The filter looks for words in the title, the description and the categories, and an exclude rule wins over an include rule. If an article you wanted is marked as filtered, compare its text with your rules; a short word can match inside a longer one. The syntax and examples are in the guide to include and exclude keyword filters.
When a source finds more eligible items than the maximum number of posts per update, the extra items are marked with the status that tells you the limit was reached. This is normal when a feed releases a batch or when you resume a source after a pause. The items are not lost and are considered at the next check. If you see this status every day and you want everything to go out sooner, raise the limit or shorten the interval within the allowed range of your plan. If you want the pace to stay gentle, leave it as it is. The effect of order and limits is explained in more detail in the guide to feed order and backdated posts.
A busy source produces many runs, most of them with nothing new. The report can be limited to runs that posted something or failed, which hides the quiet checks and puts the interesting events first. In the REST API this is the option to return only runs that posted something or failed, together with a limit and an offset for paging. Start every investigation with this view, and expand to all runs only if you need to confirm that checks happened on time.
Besides the report of a single target, PostRSS shows how many posts you made in a period, split by network, with a monthly history. Use it to see which networks are active and how close you are to the monthly allowance of your plan. The allowance and the number of targets depend on the plan, and the current figures are on the pricing page. Check the usage before you connect a large archive, since a backlog counts like any other posts when it goes out.
If you manage many targets, you can read the same data with the REST API. After signing in with a bearer token, request the report of a target with the option for runs that posted or failed, and list any run whose success flag is false. A short script can run every morning and send the result to your team chat. Because the API returns the failure reason, the message can say which source failed and why. The details of authentication and endpoints are in the guide to the PostRSS REST API v1 documentation, and the full reference is in the interactive documentation of the API.
Imagine that you published an article at nine in the morning and nothing appeared on your Facebook Page by ten. Open the report of that target and filter it to runs that posted or failed. There is no run at all after nine, which means that either the source is inactive or the interval is long. You check the source and find that it is checked once an hour, so the next run is at eleven. Nothing is wrong, and the interval is the explanation. Now imagine the opposite case: there is a run at nine fifteen with three items seen and none posted. You open the items. The new article is marked as filtered, because your exclude list contains the word sponsored and the article mentions a sponsored event. You adjust the rule to match only whole words, and the next article passes. In a third case, the article is marked as failed with a reason that mentions authorization. You reconnect the page, and the next run posts the held items. In each case the report pointed straight to the cause, and no guessing was needed.
You do not need to read reports every day. A good habit is to look once after any change to a source, once a week for the first month of a new target and whenever a follower or a colleague tells you that a post is missing. Add a note to your own documentation with the settings you chose and why, so that the next person who opens the report knows what to expect. If you manage accounts for clients, share a short screenshot of a successful run as proof that everything works. Over time you will learn the normal rhythm of each feed, and unusual patterns will stand out at once.
The PostRSS report turns guesswork into a short investigation. Check the run first to see whether the feed was read, then open the items to see what was decided for each article. Remember what the statuses mean, treat filtered and held-back items as expected behavior, read failure reasons carefully and confirm every change by looking at the next runs. For many targets, let a small script read the same data through the API every morning.
Open the report of the target, find the run at the right time and open its items. Each item has a status, and failed items include a reason.
The item was published earlier, so PostRSS does not post it again. A long list of such items is normal.
No. Items excluded by a keyword filter are not posted, do not count towards the maximum posts per update and do not count towards the plan quota.
The limit for that check was used up, so the item was held back. It is considered again at the next check.
Yes. The REST API returns the runs of a target and the items of each run, so a script can list failed runs and send an alert.
What changed in the networks, what broke, and how to fix it before it costs you reach.
Sukūrė Internet Solutions – PostRSS komanda. Kiekvienas produktas sutaupo laiko savaip.
English
Lietuviškai
Deutsch
Français
Русский
Español
Polski
Italiano
Українська
Čeština
Português
日本語
Latviešu valoda
Eesti
Magyar
Bahasa Indonesia
Türkçe
हिन्दी
Ελληνικά
العربية
ไทย
Tiếng Việt
Română
Bahasa Melayu
বাংলা
