Reverting and the render check
The post-publish render check, and how to undo something.
Publishing is not finished when WordPress returns a success. A post can be accepted and still render badly — a broken block, a theme that cannot cope with the markup. So Pressbotics checks the live post after publishing.
The render check
Every published action carries render_check with one of three values.
| render_check | Meaning |
|---|---|
| pass | The published post was fetched and rendered as expected. |
| not_yet | A scheduled post that is not public yet, so there is nothing to fetch. The scheduler verifies it the moment it goes live and writes pass or fail then. |
| fail | The live post did not render correctly. Pressbotics reverts it to draft rather than leaving it broken and public. |
A reverted action shows as Reverted in the Activity feed — a distinct state from Failed (never published) and Rejected (a person declined it). The content is still in WordPress as a draft, so nothing is lost.
Undoing something yourself
Pressbotics deliberately does not delete posts. Undo happens in WordPress, where you have the full editor and revision history:
- 1Open the post in wp-admin.
- 2Switch it to draft to take it off the site immediately, or use Revisions to restore an earlier version.
- 3If an agent update caused it, fix the content and have the agent call update_post with the corrected body rather than publishing a second post.
Preventing the next one
- Move the site to review-everything while you diagnose. A broken render you catch in the queue never reaches readers.
- Have the agent pass request_review for unusual layouts — heavy :::columns or :::cover markup, for example.
- Read post_url and render_check on the action rather than assuming a returned success means a good page.