Skip to content
VakanssiDocs
VakanssiDocs
Get Vakanssi
esc

Going live: production setup

Two standard WordPress production steps, a real cron trigger and a persistent object cache, that keep Vakanssi's background jobs on schedule and its database quieter on a live hiring site.

On this page(3)

Two pieces of ordinary WordPress production hygiene matter a little more on a hiring site than on a typical brochure site, and both are cheap. Neither is a Vakanssi requirement: the plugin works fine without them. Skip them, though, and on a quiet week its background jobs can start running late.

Trigger WP-Cron from a real cron job

WordPress’s built-in scheduler, called WP-Cron, only checks for due tasks when someone visits your site. That is fine for a busy site, but a careers page can go quiet between hiring rounds, and quiet traffic means WP-Cron checks less often, so scheduled work can run hours late, or not at all that day.

Vakanssi relies on WP-Cron for:

TaskHow oftenWhy it matters
Retention purgeDailyAnonymises applications past their data-retention deadline and deletes their CV files. See Privacy & GDPR.
Job expiry sweepDaily, at local midnightClears the cached page of each job whose closing date has passed, so a caching plugin stops showing it as open.
Webhook retry (Pro)Every 5 minutesRedelivers a failed Slack, Teams, or webhook delivery with backoff. See Integrations.
Webhook log trim (Pro)DailyTrims the delivery log to the last 30 days.

The retention purge is the one worth taking seriously: if your privacy policy promises candidates their data is deleted after a set time, a quiet site should not be the reason that promise slips.

As a safety net, Vakanssi also runs the purge as a fallback on an admin visit if the scheduled run is more than an hour overdue, throttled to once an hour, so a stalled scheduler does not leave data sitting past its deadline indefinitely.

That fallback only fires from an admin visit, so it is not a substitute for a real cron trigger on a quiet site, and Site Health keeps flagging it either way, with separate wording for a purge that has gone stale versus one that has never run at all. See Site Health flags the data-retention purge.

  1. Add this line to your site’s wp-config.php to turn off the traffic-triggered scheduler:

    define( 'DISABLE_WP_CRON', true );

  2. Have your host trigger wp-cron.php on a real schedule instead, every few minutes. Many managed WordPress hosts already do this, or offer it as a setting, so check your host’s documentation for “WP-Cron” before adding anything yourself. If you manage your own server, a crontab entry like one of these does it:

    */5 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null
*/5 * * * * cd /path/to/site && wp cron event run --due-now > /dev/null

Ask your host first

Most managed WordPress hosts already trigger cron on a real schedule, or offer it as a one-click setting. Check there before editing wp-config.php or adding a crontab entry yourself, and ask your host’s support if you are unsure which applies to your plan.

Enable a persistent object cache

Vakanssi stores a few short-lived values as WordPress transients: the answers from a rejected application form (so the candidate gets their typing back), the per-user limit on CV downloads, and a five-minute cache of the unviewed-applications count shown on the Hiring menu badge. Without a persistent object cache (Redis or Memcached), every one of those lives as a row in your site’s wp_options table.

That is unremarkable at normal traffic. Under a burst, for example a wave of spam submissions your spam protection is busy absorbing, each rejected submission writes its own row. With a persistent object cache, those writes go to memory instead, expire on their own, and add no database load.

The application form’s own rate limits are the exception, on purpose. They are counters in wp_options (named vakanssi_rc_...) updated in a single database statement, so they hold under simultaneous requests whether or not an object cache is present. An object cache does not move them, and they need nothing from you.

If your host offers Redis or Memcached, turning it on is usually a checkbox plus a small drop-in file your host installs for you. There is nothing to configure on the Vakanssi side: WordPress routes transients to the object cache automatically once one is active.

Nothing breaks without either step

Both of these are standard WordPress production practice, not Vakanssi requirements. A site without a real cron trigger or an object cache keeps working; it just runs background jobs a little later and its database a little busier under load.

Where to go next