Drupal Scheduler module for timed publishing

When teams need Drupal Scheduler for timed publishing

Teams need Drupal Scheduler when editors must put content live, or take it down, at a set date and time without someone watching the clock. Typical cases are campaign launches, product drops, press releases held until an embargo lifts, and time-limited offers that must expire on schedule. Scheduler is the contributed module that adds these controls to Drupal. According to its Drupal.org project page, it lets editors schedule publishing and unpublishing for content, media, commerce products and taxonomy terms, and about 119,687 sites report using it. If your need is limited to one content type, confirm that each type you plan to schedule is enabled in the module's configuration, since scheduling is not automatic for every entity.

The module itself carries no license fee. Drupal and all contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, so your cost is the planning, configuration, testing and ongoing maintenance of the site, not a per-site or per-editor charge for Scheduler. Budget for who will decide the schedule rules, who will test edge cases such as midnight changeovers and expired items, and who will keep the module current with Drupal core releases. Ask any implementation partner to separate these one-time build tasks from recurring update and support work in the written scope.

Before you commit to scheduling as the mechanism for launches, decide who is allowed to set and override dates and whether those dates must be approved first. Scheduler works alone or alongside an approval process, and the choice changes the roles and permissions you configure. Confirm with your own environment how scheduled actions are executed on your hosting, since timed changes depend on Drupal running its scheduled tasks reliably. Those points set the scope for the rest of this page.

What Scheduler does on a Drupal site

Scheduler adds future publish and unpublish dates to the editing workflow for content, media, commerce products and taxonomy terms. The cards below cover what editors set, what Drupal does with those dates, and the points a project team should check before relying on them for timed releases.

Scheduled publishing for content

Editors can set a future date and time for a node to become published, so a page or article goes live without someone being online at that moment. The publish date is applied by Drupal, not by the editor's browser, which means the page only appears once the site processes it. Check that the content types in scope are enabled for scheduling and that editors know which date field governs visibility.

Scheduled unpublishing for content

The same form can set an unpublish date, which removes a node from public view at a chosen time. This suits time-limited campaigns, offers and notices that must come down on a fixed date. Confirm with the content owners whether unpublished items should remain in the editorial list, and whether anyone reviews them after they expire.

Scheduling for media

Scheduler also covers media entities, so images, documents and videos can carry publish and unpublish dates. Teams use this for assets tied to a press release or a licensed document with a fixed availability window. Check which media types are enabled, because scheduling a file that is referenced by several content items can change what appears on many pages at once.

Scheduling for commerce products and terms

For sites running Drupal Commerce, product entities can be scheduled, as can taxonomy terms. A seasonal product can appear on a launch date, and a term can be added to navigation ahead of a reorganization. Confirm that product availability, pricing and stock rules are tested alongside the schedule, since publishing a product does not by itself settle those questions.

How editors enter and see dates

Scheduler adds date and time fields to the entity form, so editors enter the timing in the same place they edit the content. The scheduled state is shown on the content listing, which helps editors see what is queued. Test the interface with your real editors, including how time is displayed, because a clear view of pending items is what prevents duplicate or forgotten changes.

Time zone and cron dependency

A scheduled change is executed by Drupal's scheduled tasks, which run on cron. Drupal shows times in the time zone configured for the user or site, so a date entered in one zone may be read differently by editors in another. Ask your team to confirm cron frequency, the server time zone and the display rules before go-live, since a late cron run delays the change.

Configuration decisions before enabling Scheduler

This table compares the settings that shape how Scheduler behaves once enabled, including which entity types take dates, whether unpublish dates are needed, time zone handling and interaction with revisions. Read each row as a decision to settle with editors and the site owner before configuration, then confirm the current option names in the module's documentation for your release.

Decision	Options to weigh	When each option fits	What to confirm
Entity types that get scheduling	Nodes only, or nodes plus media, commerce products and taxonomy terms	Limit to nodes when only pages and articles need dates. Add products or terms only when merchandising or taxonomy changes must go live on a fixed date.	Which entity types the installed Scheduler release supports and which need the matching contributed module, such as Drupal Commerce for products
Unpublish dates	Publish dates only, or publish and unpublish dates	Publish-only fits campaigns that stay live. Add unpublish dates for embargoed releases, time-limited offers and content that must expire without manual action.	Whether unpublish scheduling is enabled per content type and whether it works the same for every entity type you plan to use
Time zone handling	Site default time zone, per-user time zone, or a single fixed zone for all dates	Per-user zones suit distributed editors but raise support questions. A single site zone keeps audit trails simple for teams publishing to one audience.	How Drupal's core time zone settings apply to scheduled fields, and how the date widget displays the zone to editors
Required scheduling fields	Optional dates, or dates required for specific content types	Optional fields suit content that is usually published immediately. Required fields suit embargoed or legally timed releases where a missed date would be a compliance problem.	Whether required-field behavior is configurable per content type in the release you install
Interaction with revisions and moderation	Scheduling on the default revision, or scheduling alongside Content Moderation transitions	Simple sites with no review step can schedule directly. Teams using Content Moderation need a decision on who may schedule, whether scheduled changes bypass review and which state applies at the scheduled time.	How scheduled transitions behave with your workflow states and whether approval is required before a date is accepted
Cron and execution timing	Cron every minute, or a less frequent schedule	Frequent cron suits embargoes and tight launch windows. Less frequent runs suit content where a delay of a few minutes is acceptable.	The cron interval your host supports and whether a queue or external trigger is needed for reliable execution
Permissions for scheduling	Editors may schedule their own content, or only a publisher role may set dates	Open permissions suit small teams. Restricting scheduling to publishers fits embargoed releases where one person must own the release timing.	The exact permission names the module adds and how they combine with your content type and workflow permissions
Audit and notification needs	Rely on revision history only, or add logging and notifications for scheduled actions	Revision history alone may satisfy low-risk content. Regulated or high-stakes releases usually need a record of who set a date and when it ran.	Which events the module logs and whether a separate audit or notification module is needed for your evidence requirements

How cron and time zones decide when content actually changes

Scheduler does not change content at the exact second the date passes. It queues scheduled actions, and Drupal's cron run performs them. A scheduled item therefore goes live at the first cron run after its time, so the precision of any publish time is bounded by how often cron runs and whether it runs at all. Plan for this before promising editors exact timing.

Interval sets the floor: a cron run every hour means a 10:00 publish can appear anywhere between 10:00 and 11:00 in the worst case.
Failed runs stop everything: if cron stops, scheduled publishing, unpublishing and every other cron task stop with it, often without an obvious error to editors.
Long runs delay work: a slow cron job that is still running when the next run starts can push scheduled actions later.
Cron is not a timer service: do not expect it to act between runs, even when an editor has set a precise time.
Monitoring matters: track the last successful cron run and alert on gaps.

Confirm the cron interval and the last successful run in your environment before agreeing on any timing commitment with editors.

On self-managed infrastructure, the most predictable setup is a dedicated cron job that calls Drupal from the operating system scheduler or a container job, typically through Drush. This decouples scheduled actions from web traffic and lets the platform team set the interval, logging and alerting. The trade-off is that the team owns the job, its permissions and its failure handling.

Dedicated trigger: run cron from a system timer, a Kubernetes CronJob or a similar scheduler, with a single runner per site.
Drush invocation: the command is drush cron, run as the web server user with the correct site alias.
Disable automatic cron where appropriate: turn off web-triggered cron so runs are not duplicated or delayed by traffic.
Overlap protection: prevent a new run from starting while the previous one is still working.
Logging and alerts: capture output and exit codes, and alert when runs fail or stop.

Confirm the exact cron settings for your Drupal version and hosting model in the current Drupal.org documentation before implementation, and test a scheduled publish end to end in staging.

Rollout sequence for a Scheduler implementation

This sequence takes a Drupal site from a version check to editors who schedule publishing with confidence. Each step produces a named artifact, so the team can review progress and hand over a working, documented configuration.

Confirm Drupal and PHP compatibility
Check the site's Drupal core version against the core release schedule and confirm the PHP version meets the requirements for that release. Also confirm the Scheduler release that matches the core version, since the module must be compatible with the running core. The step closes with a written compatibility note listing core, PHP, database and web server versions, which the team should verify against the current Drupal.org pages before work starts.
Enable and configure Scheduler per entity type
Install Scheduler through Composer, enable it, and decide which entity types need scheduling: content, media, commerce products or taxonomy terms. Enable only the types the editorial team will use, and set the publish and unpublish fields per bundle on the form display. The output is a configuration export committed to version control, so the setup can be reviewed and reproduced in other environments.
Set the cron and time zone policy
Scheduler acts when cron runs, so the scheduled publish time is only as accurate as the cron interval. Agree the cron frequency with the hosting team, confirm which time zone the site and each editor's account use, and document how daylight saving changes are handled. The output is a cron runbook that states the schedule, the owner, how to check that the last run completed, and what to do if a run fails.
Define editor permissions and roles
Map who may schedule, who may edit scheduled dates, and who may publish immediately. Scheduler permissions sit alongside entity and moderation permissions, so a role that can schedule but cannot publish needs a clear review path. Record the role matrix in a table that compliance and editorial leads can sign off, and export the role configuration with the rest of the site configuration.
Test publish and unpublish against revisions
Build a test matrix covering each entity type, each permitted role, future publish and unpublish dates, edits made after scheduling, and content with pending revisions. Check that the live revision changes at the expected time and that revision history shows what happened. Include cases with Content Moderation enabled, where a scheduled action must not bypass the approval states. The output is a signed test matrix with pass and fail results and any defects logged.
Validate the embargo and moderation interplay
For embargoed releases, confirm that a scheduled publish cannot make content visible before the approval state required by the editorial workflow. Test the sequence of review, approval and scheduled publication with the actual workflow configuration. The output is a short workflow diagram with the states, transitions and scheduled actions, reviewed by the content owner before go-live.
Train editors and hand over
Run a training session on the real editorial forms, using the time zone and cron behavior documented in earlier steps. Provide editor guidance that covers how to schedule, how to change or cancel a schedule, what cron delays look like in practice, and who to contact. The handover closes with the configuration export, test matrix, cron runbook and editor guidance filed together, plus a named owner for ongoing maintenance.

How Scheduler works with Content Moderation and embargoed releases

The key question for this section is whether a scheduled date bypasses review. Scheduler stores a future publish or unpublish date on a node, and the publish step itself is applied by cron, so the site's permissions and workflow setup decide who can set that date and what state the content must be in when the date arrives. Where Content Moderation is enabled with the core Workflows module, the reader needs to confirm three things in a staging copy: which roles can see and set the Scheduler fields, whether the scheduled transition is limited to a state the workflow already allows (for example, a state that represents approved content), and what happens to a draft or forward revision that exists when the date passes. Do not assume that a scheduled date counts as an approval. Treat it as a configuration choice that your editorial policy must sign off on.

Embargoed releases are the case where these answers matter most. A press release, financial disclosure or regulatory notice may need to go live at an exact minute, be visible only to a restricted group before that minute, and leave a record of who set the time and who approved the content. Plan the approval chain first, then decide whether the schedule is set by the approver, by a separate publisher role, or by the author with a mandatory review step before the date. Verify the time zone handling on the staging site with a test item scheduled across a daylight saving change, and check that the revision history and any moderation log show the scheduling actions. If access to unpublished embargoed content must be limited further, pair the schedule with access controls or a separate workflow, and confirm that cron runs on a schedule your press office can rely on, since a late cron run delays the release.

What drives Scheduler effort and cost

This table lists the factors that change the size of a Scheduler project and the levers that keep each one manageable. Read it before writing a scope, because most of the effort comes from the number of entity types, the moderation rules and the cron setup rather than from enabling the module itself. The main takeaway is that a narrow, tested scope costs less to build and far less to support after launch.

Driver	Why it changes effort or cost	How to keep it down
Entity types in scope	Scheduler covers content, media, commerce products and taxonomy terms, and each enabled type adds form fields, permissions and test cases.	Enable only the entity types and bundles editors need to schedule, and document the rest as out of scope.
Content Moderation workflows	Scheduled transitions must respect review states, so each workflow adds rules for who may schedule and what happens at the scheduled time.	Reuse one tested permission model across bundles, and limit scheduled transitions to the states your editorial process already defines.
Cron infrastructure and monitoring	Scheduled actions only run when cron runs, so the schedule, queue behavior and failure alerts all need design and ownership.	Confirm the cron method your hosting supports, set a run interval agreed with editors, and alert on missed runs.
Time zone requirements	Editors in several regions and content that must go live at a local hour raise questions about storage, display and daylight saving changes.	Agree one authoritative time zone for each site or content type, and test dates near daylight saving transitions.
Custom code or ECA automation	Notifications, syndication or cache clearing triggered by scheduled events may need custom code or ECA models, which carry their own build and upgrade work.	Start with the module's built-in behavior, add ECA or custom events only for documented needs, and keep them under configuration management.
Embargoed release handling	Embargoes add review, access and audit requirements, so the scope grows with the number of people who can see content before publication.	Define the embargo rules in writing and limit the roles that can override a scheduled date.
Test coverage	Publishing mistakes are visible to the public, so tests for each entity type, moderation state and time zone add effort before launch.	Agree a test matrix in the scope, automate the critical publish and unpublish paths, and confirm the tests run on each Drupal update.
Upgrade and support path	Each Drupal core release and Scheduler update may affect scheduled behavior, and the cost of this recurs for the life of the site.	Pin the supported Drupal and Scheduler versions in the plan and confirm the release timing with the Drupal core release schedule before work starts.

How Scheduler connects to the rest of the platform

Scheduler is simple on its own, but its timed actions depend on the editorial, staging, cron and caching layers around it. Each connection below is a place where a scheduled change can behave differently from what editors expect.

Content Moderation and Workflows

Scheduler sets publish and unpublish dates on content, but whether a scheduled action respects the review states you have defined depends on how the Workflows and Content Moderation modules are configured. Confirm which transitions are allowed to fire on a date, and whether an editor can schedule a revision that has not yet passed review. Test an unpublish date on a revision that is still in draft, since the outcome determines whether unreviewed text can reach the public site.

Workspaces for staged releases

Workspaces let a team stage a set of changes and publish them together, which is often the reason to use scheduled publishing in a release. Check how scheduled dates behave inside a workspace before the workspace is deployed, and decide whether a coordinated release should be scheduled as one event or as individual content dates. Mixed approaches tend to produce partially published campaigns when one date slips.

Cron and queue infrastructure

Scheduled transitions are only applied when cron runs, so the publish time is only as accurate as the cron schedule. Confirm how often cron runs in your hosting stack, whether it runs through a system scheduler or a web request, and who is alerted when a run fails. Long-running cron jobs on a busy site can delay scheduled changes, so measure the lag between a scheduled time and the actual publish time in a test environment.

Caching and CDN purging

A scheduled publish changes content without an editor clicking save, so reverse proxies and CDNs must still receive the invalidation that Drupal sends for that change. Verify in your own stack that cache tags are passed on the scheduled event, that anonymous visitors see the new page within the expected window, and that unpublished pages stop being served. Treat this as a test case, not an assumption about how your CDN behaves.

Editorial permission models

Scheduling rights are granted through Drupal permissions, so an editor who can publish content may or may not be able to schedule it, and the answer can differ by content type. Map who may set publish dates, who may change them after approval and who may schedule unpublishing, then test those roles against each content type and any taxonomy or product entities in scope. Access models such as section-based editing add another layer that needs its own test.

Dependence on surrounding modules

Integrations with search indexes, CRMs, commerce catalogs and external caches depend on the modules and hooks around Scheduler, not on Scheduler itself. A scheduled publish may trigger an indexing update in one system and not another, depending on how each module reacts to the entity save. Ask which downstream systems must learn about a scheduled change, then test each one with a real scheduled event before launch.

Questions teams ask before bringing in a partner for Scheduler

What drives the cost of a Scheduler implementation?

The cost depends mainly on how many content types, media types, product types and taxonomy vocabularies need scheduling, and on how much the publishing rules differ between them. A partner is paid for scoping the configuration, building or adjusting any custom behavior, writing the test plan, running the tests with your editors and handing over documentation. The one-time work is the setup and testing. Recurring costs come from updates to the module and from any support retainer you choose. Ask for a quote that lists each content type, the moderation states involved, the test cases and the handover items as separate lines.

How long does a typical Scheduler configuration and test cycle take?

Duration depends on the factors in your environment rather than on a fixed number. The main drivers are the number of content types being scheduled, whether Content Moderation or embargo rules must be respected, how many roles and editors need sign-off, and whether a staging environment with a working cron schedule is available. Testing takes longer than configuration when time zones, daylight saving changes and multi-site setups are involved. Ask the partner to tie the timeline to the written scope and to a named staging environment, so the schedule reflects your actual dependencies.

What must our team provide before a partner starts?

A partner needs a clear picture of what will be scheduled and who may schedule it. Prepare the content model for every entity type in scope, a list of roles and the permissions each role should hold, and the publishing rules your editors follow today. You should also provide a staging environment that matches production closely, with a working cron job, sample content and a named product owner who can approve test results. If Content Moderation is in use, share the workflow states and transitions. Missing items usually turn into change requests, so list them in the scope document.

Can our internal team implement Scheduler on its own?

Yes, a capable internal Drupal team can install and configure Scheduler without outside help, provided it has someone who understands Drupal permissions, content moderation and cron. The module is used on a very large number of sites, so the configuration path is well trodden. The harder part is verification: confirming that scheduled changes fire at the right moment across time zones, that revisions and moderation states behave as expected, and that editors understand the workflow. Many teams bring in a partner only for that test plan and for documentation, which keeps the internal team in control of the build.

How do time zones and cron affect when scheduled changes go live?

Scheduled changes depend on cron running regularly, so a site with infrequent or failing cron jobs will publish late. Time zones matter because editors enter dates in their own zone, while the server stores and compares times in its configured zone. Confirm the site's default time zone, each user's time zone setting and the server clock before testing. Test a change at a boundary such as a daylight saving transition and check that the publish time shown to editors matches the moment the content appears. Record the cron interval you run in production, since it sets the worst-case delay you should accept for embargoed material.

Does Scheduler work with Content Moderation and embargoed releases?

Scheduler can be combined with Content Moderation, but the interaction needs explicit design. A scheduled transition must be allowed by the workflow, and the person who scheduled it must hold the permissions for the target state. For embargoed releases, decide whether the scheduled publish is the only release path, whether anyone can edit the item before it goes live, and how a last-minute hold is applied. Test each path with a sample embargo, including an unpublish date and an edit made after scheduling. Document the rules so that compliance and communications teams know exactly what the system will do.

How are Scheduler upgrades handled over time?

Scheduler is a contributed module, so it is updated through the normal Drupal update process, and its compatibility depends on the Drupal core version in use. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, so check the module release against your target core before each major upgrade. Core bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, which sets a predictable test rhythm. Ask any partner to include regression tests for scheduled publishing in each upgrade cycle, and to confirm that the PHP version meets the core requirement, since Drupal 11 requires PHP 8.3 or later.

How DeployOpen scopes and delivers Scheduler work

DeployOpen plans and builds Drupal Scheduler for timed publishing inside infrastructure you control, starting from a written scope that names the content types, cron setup, time zone rules and workflow interactions in play. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any build work starts.

How we scope

Inventory which content types, media, products and terms need timed publishing and which editors will use it.
Document the cron setup, time zone expectations and how scheduled dates map to your editorial calendar.
Agree in writing how Scheduler interacts with Content Moderation, embargoed releases and any custom workflows.

How we build

Configure Scheduler and its permissions for each entity type, then test scheduled publish and unpublish actions end to end.
Verify cron runs on your hosting, including timing, failure alerts and behavior when the site is in maintenance.
Test time zone handling with editors in several locales and document any custom code added for your rules.

How we hand over

Deliver written editor guidance covering scheduling steps, expected publish times and known edge cases.
Provide a runbook for cron monitoring, log checks and troubleshooting missed scheduled actions.
Record configuration in version control so the Scheduler setup can be reviewed and reproduced during upgrades.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan Scheduler updates alongside Drupal core releases, so testing of scheduled actions runs before each change reaches production.
Ask any quote to name the support hours, response expectations and which environments are covered before work starts.

Drupal Scheduler for timed publishing