Revive Social Docs

Appearance

How to fix Revive Social not posting ​

If Revive Social does not share posts to social media for your website, then the issue might be with WordPress' Cron. This can be due to your website not having enough visitors or something is wrong with WordPress Cron, such as it being turned off without a replacement.

There are two ways to go about addressing this issue; the first one( Method 1) is the simplest, and the second(Method 2) involves creating a "True Cron" via your Cpanel account from your Web host.

If you are having trouble implementing Method 2, then please forward this document to your Web host support personnel. They will be able to implement the true cron for you. A recommended interval for the cron job would be once every 10 minutes.

In this article

Check whether any posts are eligible to be shared ​

Before troubleshooting WP-Cron, check whether Revive Social has any posts it can actually share.

Revive Social only queues posts that match your sharing filters from Revive Social > Dashboard > General Settings. If no posts match those filters, nothing will be shared even when your accounts are connected and your schedule is active.

How Minimum Post Age and Maximum Post Age work together ​

The Minimum Post Age and Maximum Post Age settings define one date window for eligible posts:

  • Posts newer than your Minimum Post Age are skipped.
  • Posts older than your Maximum Post Age are skipped.

For example, if Minimum Post Age is 1 day and Maximum Post Age is 4 days, Revive Social shares only posts published between 1 and 4 days ago. Newer and older posts are excluded.

Custom Schedule does not override eligibility settings ​

The Custom Schedule tab controls when Revive Social tries to share posts. It does not change which posts are eligible.

Even with a correct recurring or fixed schedule, Revive Social cannot post if no content matches your current age window and filters.

What to do if no posts match the age window ​

  1. Go to Revive Social > Dashboard > General Settings.
  2. Review your Minimum Post Age and Maximum Post Age values.
  3. Compare those values with the publish dates of your WordPress posts.
  4. Widen the age window (for example, lower Minimum Post Age or increase Maximum Post Age) so at least some posts are eligible.
  5. If needed, publish content that fits your configured age range.

📝 Note: If you already have eligible posts and Revive Social is still not posting, continue with the WP-Cron and Action Scheduler checks below.

Action Scheduler Support ​

Revive Social supports Action Scheduler, a more robust and scalable background processing library. If your site already uses a plugin that includes Action Scheduler (such as WooCommerce), Revive Social will automatically detect it and use it instead of the default WP-Cron system. This can improve the reliability and performance of scheduled posts.

If no such plugin is present, Revive Social will continue to function normally using WP-Cron, with no additional setup required.

Check whether the Revive Social cron event exists ​

If your Sharing Queue still contains posts but nothing is being shared and the Sharing Logs stay empty, check whether Revive Social's rop_cron_job event is scheduled.

  1. If your site has a Tools > Scheduled Actions page, open it and search for rop_cron_job.
  2. If your site does not have Tools > Scheduled Actions, inspect your WordPress cron events with a plugin such as WP Crontrol and search for rop_cron_job there.

Here is how to interpret the result:

  • If rop_cron_job is present and Pending, confirm the scheduled time is still in the future. A future timestamp is normal. An overdue Pending action can mean the broader queue is congested.
  • If rop_cron_job is present but Failed, open the most recent entry and check the log message.
  • If rop_cron_job is missing entirely, WordPress cron may not be firing, or it may be disabled without a replacement. In that case, the queue can still contain posts, but no new shares or Sharing Logs are generated because the scheduler never runs.

If rop_cron_job is Pending but never runs ​

If your Sharing Queue contains posts, Sharing Logs stay empty, and rop_cron_job stays Pending past its scheduled time, the problem is often a delayed Action Scheduler queue instead of a missing Revive Social event.

Check the full Action Scheduler queue ​

  1. Go to Tools > Scheduled Actions.
  2. Open the Pending tab.
  3. Note the total Pending count.
  4. Review the Hook and Group columns to identify repeated action names or groups that dominate the queue.

📝 Info: Action Scheduler is shared across plugins. A large backlog created by another plugin can delay Revive Social actions even when your Revive Social accounts, schedule, and queue are configured correctly.

Clear the backlog and stop it from returning ​

  1. Record the repeated hook or group names before making changes.
  2. Update the plugin that owns those repeated actions.
  3. Reduce or temporarily disable the plugin feature that keeps generating excessive scheduled actions.
  4. In Tools > Scheduled Actions, clear or cancel stale Pending actions only for the repeated hooks/groups tied to that source.
  5. Configure a real cron job that reliably reaches wp-cron.php by following How to set up a real cron job in WordPress.
  6. Keep the recommended cron interval at once every 10 minutes.

⚠️ Warning: Do not bulk-delete every scheduled action. Keep current Revive Social actions (including rop_cron_job) and clean only the stale backlog source. If you are unsure which actions are safe to remove, contact that plugin's support team or your hosting provider first.

If rop_cron_job is missing ​

  1. Follow Method 1 or Method 2 below to replace unreliable or disabled WP-Cron with a real cron job.
  2. Set the cron interval to once every 10 minutes.
  3. Go to Revive Social > Dashboard and click Start Sharing if sharing is not already active.
  4. Wait for the next cron interval, then check again for rop_cron_job.

⚠️ Warning: If the Sharing Logs already show a social network, API, or credential error, troubleshoot that connection instead of changing WP-Cron. If no posts are eligible to share, adjust your Minimum Post Age, Maximum Post Age, and other sharing filters first.

Sharing stops with "Unknown error occurred" in Scheduled Actions ​

If Revive Social reverts to Sharing Not Started on its own and the Scheduled Actions log shows "Unknown error occurred," a sharing run was cut short before it could finish.

To confirm the cause: ​

  1. Go to Tools > Scheduled Actions in your WordPress admin.
  2. In the search box, enter rop_cron_job and press Enter. Then repeat the search for rop_cron_job_publish_now.
  3. Click the Failed tab.
  4. Open the most recent failed entry and note the exact log message, for example action marked as failed after 300 seconds.
  5. Clear the search box and look through the Failed tab again. Note whether actions belonging to other plugins fail after the same number of seconds.

Why this happens: ​

Each time the sharing schedule fires, Revive Social processes all connected accounts in a single background task. Sites with many connected social accounts, or sites where social network APIs respond slowly, can take several minutes to finish a single run.

A message such as action marked as failed after 300 seconds records the point at which the scheduler gave up on a run that never reported back. It does not tell you what stopped the run. The run can be ended by a PHP limit, or by your web server closing the background request that was doing the work. Either way, the run stops before it can schedule the next one, so nothing triggers sharing again and the dashboard falls back to Sharing Not Started.

The Failed tab tells you which of the two it is:

  • If only Revive Social actions fail, a PHP limit is the more likely cause.
  • If unrelated plugins also fail after the same number of seconds, the limit is being applied by your server to every background request, not by Revive Social.

If only Revive Social actions fail: ​

Ask your hosting provider to increase the following PHP settings:

  • max_execution_time: set it higher than the number of seconds in the failure message, for example 600
  • memory_limit: set to at least 512M

If actions from several plugins fail after the same number of seconds: ​

Your web server is closing background requests before they finish, and raising the PHP settings above will not help, because the server ends the request before PHP reaches its own limit. This has been confirmed on LiteSpeed servers, which can stop background and loopback requests after five minutes.

Replace WordPress' default cron with a cron job that your host runs on the server itself, so a sharing run no longer depends on a web request that the server can close:

  1. Ask your hosting provider to add a cron job that runs the wp-cron.php file directly on the server, rather than by requesting it over the web. Ask for an interval of once every 10 minutes.
  2. Once the server cron job is in place, turn off the default WP-Cron by adding define('DISABLE_WP_CRON', true); to your wp-config.php file, as described in Method 1, Step 1 below.
  3. Go to Revive Social > Dashboard and click Start Sharing.

⚠️ Warning: An external service that calls your site over the web on a schedule, such as the one described in Method 1 below, is a fine general replacement for WP-Cron, but it does not solve this particular problem. Those calls reach WordPress through the same web server, so the same time limit applies to them.

If failures continue after raising the PHP limits: ​

Some web servers stop long-running background requests themselves, whatever PHP limits your host has set. LiteSpeed is one of them. When that is what is happening, raising max_execution_time and memory_limit changes nothing, because PHP is not what ends the request.

To check whether the problem affects the whole site rather than Revive Social alone:

  1. Go to Tools > Scheduled Actions and open the Failed tab.
  2. Look at the failed entries belonging to plugins other than Revive Social.
  3. If background tasks from several unrelated plugins are failing as well, the cause is on the server rather than in Revive Social. Ask your hosting provider whether the web server stops long-running background requests.

If your site runs on LiteSpeed, your hosting provider can let these background requests finish by adding the following line at the top of the .htaccess file in your WordPress root folder:

apache
SetEnv noabort 1

⚠️ Warning: Back up your .htaccess file before you change it. An incorrect .htaccess file can make your entire site unreachable. If your site returns an error after the change, restore the backup and contact your hosting provider. If you do not have file access, send this instruction to your host instead of editing the file yourself.

After the change, go to Revive Social > Dashboard and click Start Sharing. Watch the Failed tab under Tools > Scheduled Actions for two to three days, and confirm that sharing stays active and that new entries keep appearing in Sharing Logs.

📝 Note: If long-running requests are still being cut short after the server cron job is running, ask your host whether SetEnv noabort 1 should be added to the .htaccess file in your site's root folder. This setting applies to LiteSpeed servers only, so let your host make or review the change, ask them to back up .htaccess first, and have the line removed if your site returns a server error.

Confirm that sharing stays stable: ​

  1. Over the next two to three days, check Tools > Scheduled Actions > Failed and confirm that no new rop_cron_job or rop_cron_job_publish_now entries appear.
  2. Open the Sharing Logs tab in Revive Social > Dashboard and confirm that new entries keep appearing.
  3. Confirm that the dashboard still shows sharing as active instead of reverting to Sharing Not Started.

📝 Note: If the error message in the Failed tab is different from the one described here, or if failures continue after you make these changes, contact support and include the exact text of the failed action log entry.

How to confirm the scheduler is working again ​

  1. Check Tools > Scheduled Actions > Pending and confirm the total Pending count continues to decrease over time.
  2. Search for rop_cron_job and confirm it appears in Scheduled Actions or your cron events list.
  3. Wait for the next scheduled run and confirm rop_cron_job completes instead of remaining overdue in Pending.
  4. Return to Revive Social > Dashboard and open Sharing Logs.
  5. Confirm that new log entries appear and that posts start leaving the Sharing Queue.
  6. If rop_cron_job is still missing after you set up a real cron job and restart sharing, ask your hosting provider to confirm that the cron job is reaching wp-cron.php successfully. If needed, contact support with screenshots of your queue, your cron event search, and your cron configuration.

Check Sharing Logs for social network errors ​

If only one social network (such as LinkedIn) is failing while others continue to post, check the Revive Social Sharing Logs before troubleshooting WP-Cron. A platform-level API error requires a different fix from a cron problem.

To view the Sharing Logs, go to Revive Social > Dashboard and click the Sharing Logs tab.

LinkedIn error: NONEXISTENT_VERSION / Requested version is not active ​

If the Sharing Logs contain a line similar to:

Cannot share to linkedin. Error: Array ( [status] => 426 [code] => NONEXISTENT_VERSION [message] => Requested version YYYYMM is not active )

This means Revive Social is requesting a LinkedIn API version that LinkedIn no longer accepts. The fix is a plugin update - do not reconnect your LinkedIn account or create a new LinkedIn App, as those steps will not resolve this error.

To fix: ​

  1. Go to Plugins > Installed Plugins in your WordPress dashboard.
  2. Update Revive Social and the Revive Social Pro Add-on to the latest available versions.
  3. Retry sharing to LinkedIn.

If the error persists after updating, open a support ticket and include:

  • The exact text of the Sharing Logs entry.
  • Revive Social version and Revive Social Pro Add-on version.
  • WordPress version and PHP version.
  • Whether the failure happens on scheduled shares, instant shares, or both.

Method 1. ​

You can create a Cron job for Revive Social using Cronjob.org:

Step 1. ​

Turn off the default WP Cron by editing the wp-config.php file (located in the root of the folder where WordPress is installed). Open the wp-config.php file, add a new line after define('WP_DEBUG', false); then add the following code on the new line:

define('DISABLE_WP_CRON', true);

Save your changes after you've added the new line.

If you are not sure how to navigate to this file via your Cpanel or FTP, you can install the following plugin, which will allow you to edit the files on your server directly from within WordPress: https://wordpress.org/plugins/file-manager-advanced/

Once the plugin is installed, you should have a new option called File Manager inside your dashboard. Click the menu item to bring up the files:

Right-click on wp-config.php and select Editor to start editing the file. Add the following line:

define('DISABLE_WP_CRON', true);

Inside the file after define('WP_DEBUG', false); So it looks like below_:_

(Be sure to save your changes when you're done editing the file and then delete the File Manager plugin if no longer needed).

Step 2. ​

Create an account on https://console.cron-job.org/signup, then log into your account on the website.

Step 3. ​

Click the Create Cron Job button to create a new cron job.

Step 4. ​

Fill out the details of the Cron job. For Title, enter anything you wish; for Address, enter your website domain suffixed with /wp-cron.php?doing_wp_cron.

Example: https://yourwebsitedomain.com/wp-cron.php?doing_wp_cron

  • Change yourwebsitedomain.com to your actual website domain.
  • If your website does not have SSL, then change https to http

Step 5. ​

Set the Cron schedule; we recommend every 10 minutes:

Step 6. ​

Check the option to save responses so that you can see if the cron job is executed successfully, then click the Create Cronjob button.

That's it! Your cron job should now be created, and if you did Steps 4 & 5 correctly, then you should see success messages in the History section of https://cron-job.org, letting you know that the cron job ran successfully.

Method 2. ​

The other method to fix the issue is creating a true cron for your website. This requires you to have access to your cPanel account to make the following changes.

📝 Note: HostGator has gone ahead and created a pretty detailed document on how to create a true cron for WordPress, so we will use it. Please go here to view the document: How to create a true cron for WordPress. The screenshots from the article refer to HostGator, so the interface might be different according to the hosting provider.

If you are not comfortable with performing any of these methods, then we highly recommend you contact your web host for assistance. They will be able to perform either method for you in no time.

Still, having issues? Contact us here: Submit Ticket

Was this helpful?

Copyright (c) 2026 Revive Social