Recurring Events on WordPress: Rules That Do Not Break

Recurring events on WordPress stay reliable when you store one rule instead of many hand-copied dates, tie every start time to a named time zone, and decide before launch how editing, cancelling and booking a single date will work. Most plugins can repeat an event. They differ on what happens when you change one date, skip one date or move clocks forward. This guide compares what four plugins document and gives you a test list to run before members rely on a series.

Plugin details below were read from each plugin’s own documentation in October 2026. Recurrence features change between releases, so check the current docs for anything that affects your setup.

In this guide

• What a recurring event and a recurrence rule are
• What four WordPress plugins document about recurrence, in one table
• Editing one date versus the whole series
• Time zones and daylight saving time
• Month-end dates that do not exist
• Cancelled instances
• RSVPs and tickets per date
• Duplicate content and search
• A testing checklist
• Moving a series to another plugin
• Questions people ask

What is a recurring event, and what is a recurrence rule?

A recurring event is one event that happens on many dates, described by a rule rather than a list. The rule says how often it repeats, on which days, and when it stops. The plugin then works out the individual dates, called occurrences or instances.

The standard way to write such a rule comes from iCalendar, the format behind calendar files and feeds. It is defined in RFC 5545, titled “Internet Calendaring and Scheduling Core Object Specification (iCalendar)” and published in September 2009. Its repeat-pattern property is called RRULE. The same document defines EXDATE, a list of dates that are taken out of the generated set.

An RRULE is a short line of parts separated by semicolons. Here is what it looks like in practice:

• FREQ=WEEKLY repeats every week. FREQ is the only part the standard requires, and it can appear only once. The allowed values run from SECONDLY up to YEARLY, with DAILY, WEEKLY and MONTHLY in between.
• INTERVAL=2 makes it every second period, so FREQ=WEEKLY;INTERVAL=2 means every other week.
• BYDAY=-1FR picks the weekday, and the number in front is the position. The standard lets a BYDAY entry carry a sign and an ordinal, so a rule can mean “the last Friday”.
• BYMONTHDAY=15 picks a day of the month.
• COUNT or UNTIL ends the series. The standard says they must not appear in the same rule, so a series ends by number or by date, never both.

You will rarely type this yourself. Event plugins hide it behind a form with a dropdown for the pattern and fields for the end. But the same ideas appear in every form: a frequency, an interval, a day rule and an end. Knowing them tells you why some patterns are simple and others are not.

How do the main WordPress plugins handle recurring events?

All four plugins below can repeat an event, but they model it differently. Some keep one parent event with a rule, some create a separate event for every date, and they offer different tools for skipping or changing one date. The table shows what each plugin’s own documentation states.

Eventonomy is made by Wbcom Designs, the company behind Reign. We list it first because it is our product, and we say where the others do things it does not.

	Eventonomy	The Events Calendar	Modern Events Calendar	Events Manager
Repeat patterns documented	Repeats: None, Daily, Weekly, Monthly, Yearly, with an “Every” interval. Specific weekdays, “2nd Tuesday” and “last Friday” style rules, and a fixed day of the month need a paid licence, check the product page	Once, Daily, Weekly, Monthly, Yearly. Examples include every three days and the first Friday of each month. One pattern rule per event	Daily, Weekly, Monthly, Yearly, Every Weekday, Every Weekend, Certain Weekdays, Custom Days and Advanced, such as the second Monday of each month	Docs mention “extended options for recurrence patterns” without listing them
Skipping dates	Cancel this date in the editor, and the date can be restored. A skip-dates list needs a paid licence, check the product page	Exceptions by pattern or by single date. One pattern exception per event, unlimited single-date exceptions	Exceptional Days module, switched on in MEC settings, then dates are entered	Not described on the recurring events page
Changing one date	No “this occurrence only” edit. Edits apply to the whole series, and a date that must differ becomes a separate one-off event	Open the Series, click Edit on the instance, then choose “This event” when saving	“Edit Per Occurrence” setting lets you override listed fields such as tickets, cost and location	Each recurrence is its own event, so editing one changes only that one. A detach link separates it from the set
How a series ends	End-after count and end-on date need a paid licence, check the product page. Dates are created 12 months ahead by default, from 1 to 60 months	Never (up to 60 months ahead), on a date (inclusive), or after a number of occurrences	Never, On a date, or After a number of occurrences	The start and end dates set the window in which occurrences fall
Time zone	Stores times in UTC and shows the event’s own zone for event dates	Docs link to a separate time zone and daylight saving article	A time zone can be set per event once enabled in settings	Every event has its own time zone
Bookings and tickets	RSVP details: check the product page. Reminders name each date	Standard tickets cannot be added to recurring events. Series Passes are the suggested route	Edit Per Occurrence can override Total Booking Limit and Tickets	Bookings apply to one day, not the whole set

Sources: the Eventonomy recurring events, advanced recurrence and time zone rule docs on eventonomy.org, The Events Calendar recurring events article, the Modern Events Calendar Add Event article on webnus.net, and the Events Manager recurring events and time zone pages on wp-events-plugin.com.

Where The Events Calendar is the better pick

The Events Calendar documents series tooling in depth. It lets you stack several patterns in a Series and gives you a pattern-based exception, such as “not the third Friday”. If your schedule has layered rules and you want editors who already know the plugin, it is a strong choice. Its docs also say you can raise the “never ends” limit with a filter, and they warn that events extending far into the future can slow performance.

Where Modern Events Calendar is the better pick

Modern Events Calendar offers the widest list of ready-made patterns, including every weekday, every weekend and custom days. Its per-occurrence override list is the longest of the four, covering booking limit, tickets, cost, location and more. If you run a schedule where every date can have different tickets or a different speaker, that setting matters.

Where Events Manager is the better pick

Events Manager treats each recurrence as its own event, which is easy to reason about. Edit one, and only that one changes. If you like the idea that a series is just a convenient way to create ordinary events, this model feels natural. Its docs also warn that rescheduling a recurring event deletes and recreates the information attached to the recurrences, such as bookings, so reschedule with care.

Where Eventonomy fits

Eventonomy writes a real row for each date and pre-computes them, so long series do not slow a page down, according to its product page. It keeps the model simple: one series, edited as a whole, with a clear way to cancel one date. That suits a community that runs a weekly call or a monthly meetup. If you need per-date overrides of the kind Modern Events Calendar offers, use a separate one-off event for the odd date or choose a different plugin. For the wider plugin picture, see our roundup of WordPress event calendar plugins and the alternatives to The Events Calendar.

Should you edit one date or the whole series?

Edit the whole series when the rule itself changes, and edit one date only when a single meeting differs. The trouble starts when a tool lets you do the second and quietly breaks the first.

The plugins above each draw the line in a different place. The Events Calendar asks you to open the Series, edit the instance, and confirm “This event” when you save, and the edited date then sits as a single event within the Series. Events Manager makes every recurrence an ordinary event, so editing one never touches the rest, and the detach link cuts it loose from the set. Modern Events Calendar keeps the series intact and lets you override chosen fields on one occurrence. Eventonomy edits the series as a whole and has no single-date edit.

Pick the model that matches how often your dates differ. On a Reign site the choice does not change the design, because the theme styles whichever plugin you use.

• Almost never differ: a whole-series model is fine. A weekly office hour with an occasional cancellation needs only a cancel action.
• Sometimes differ in small ways: per-occurrence overrides fit, for example a guest speaker or a different room.
• Often differ: every date is really its own event. Create them as separate events, or use a model where each date is its own record.

One rule helps in all cases. Decide who is allowed to detach or override a date. An editor who changes the title on one date may think they changed the series, and the other forty dates keep the old title. Write the answer in your team notes and use it in training.

How do time zones and daylight saving time affect recurring events?

A weekly 7 pm event should stay at 7 pm local time all year, even though the same moment shifts by an hour in UTC when clocks change. So the rule must be attached to a named time zone, such as a city, and not to a fixed offset from UTC. If the plugin stores only the offset, one half of the year will be an hour off.

Here is why. UTC, Coordinated Universal Time, does not change with the seasons. A London evening event is an hour different from UTC in summer than in winter. Store the 7 pm as a fixed UTC time and the event drifts by an hour for attendees when the clocks move. Store the rule in the event’s local time zone and each date is computed at 7 pm local.

RFC 5545 explains what happens at the edges. A local time given with no time zone is called floating time and is read as whatever local time the viewer is in. If a time is ambiguous because the clocks go back and the same hour happens twice, the standard says the value refers to the first occurrence. If a time is skipped because the clocks go forward, the standard says the value is interpreted using the UTC offset from before the gap. In plain terms, an event set for 2:30 am on the night clocks jump forward has no real 2:30 am, and the calendar needs a rule for it. Most community events are not scheduled in that window, but a late-night stream or an early-morning call can be.

What the plugins document:

• Events Manager gives every event its own time zone, and its time zone page warns that bulk-changing event time zones overwrites all events, including those with custom ones.
• Modern Events Calendar can set a time zone per event, after you enable it in its single event settings.
• Eventonomy stores each instant in UTC and shows an event’s own zone for its dates. The site zone is used for grouping, such as day headers and calendar grid cells. Its docs say a zone abbreviation shows only when the event zone and the site zone differ.
• The Events Calendar documents time zones and daylight saving in a separate article, so read that one before you commit.

The practical test is simple. Create a weekly event that crosses a clock change in your region, then check the displayed time on both sides of it. Do this in the calendar, on the single event page, in the email reminder and in the exported calendar file. Four places, and any one can be wrong while the others are right.

What happens when a monthly event lands on the 31st?

When a monthly rule asks for a day that does not exist, such as the 31st in a 30-day month, the standard says that date is skipped. RFC 5545 states that recurrence instances with an invalid date, with February 30 as its example, must be ignored and must not be counted as part of the recurrence set.

That has two effects that catch organisers out. A “day 31 of every month” rule produces no event in short months. And with a COUNT, the skipped months are not counted either, so the series simply runs over more calendar months than you expected. If you want “the last day of the month”, write the rule that way, not as day 31.

The cleaner patterns avoid the problem:

• Nth weekday: “the second Tuesday” exists in every month. The standard allows a signed ordinal in front of the weekday, so “the last Friday” is also valid.
• Last day: use a rule that means last day, if your plugin has one. Eventonomy’s advanced recurrence page says its engine can land on month-end in short months. That belongs to its paid rules, so check the product page.
• Days 1 to 28: a fixed day within that range exists in every month, including February.

Check your own plugin with a deliberate test. Set the rule to the 31st, start in January, and look at the months after. If February, April, June, September and November are missing, the plugin follows the standard. If they land on the 30th or the 28th, that is the plugin’s own choice, and you should decide whether that suits your members.

How should you handle cancelled instances?

Cancel a single date with the plugin’s own cancel or exception tool, and do not delete the event row by hand. A cancel tool records that the date is skipped, so the series keeps going and the date can come back. A hand deletion may be rebuilt the next time the plugin recomputes the series.

The Events Calendar documents exceptions, which exclude dates by pattern or by individual date. Modern Events Calendar documents an Exceptional Days module for skipping dates such as holidays. Eventonomy has a Cancel this date action under the event’s upcoming dates, and its docs say cancelled dates leave the calendar, browse views and the public event page, while the rest of the series is untouched. A cancelled date can be restored. Events Manager’s page does not mention exceptions, so the route there is to edit or delete the single recurrence, which is its own event.

Cancelling has a second half: telling people. Ask these questions before you rely on it.

• Does anyone who booked or RSVPed get an email when a date is cancelled?
• Does the page for that date show “cancelled”, or does it simply disappear and return an error to anyone with the old link?
• Is the date still in calendar files people already subscribed to?

If the page vanishes, members with old bookmarks land on a dead page. A short redirect to the series page, or a visible “cancelled” notice, is a kinder result. Test what your plugin does and write down the answer.

Should RSVPs and tickets belong to one date or the whole series?

They should belong to one date, because people attend a date, not a series. A member who says yes to this Thursday has not said yes to every Thursday for a year, and capacity is a limit for one room on one evening.

The plugins differ, so read the booking part of each doc before you choose:

• Events Manager says bookings apply to one day, not the whole set. It also warns that rescheduling deletes and recreates attached information, such as bookings, so a reschedule can wipe the people who signed up.
• The Events Calendar says standard tickets cannot be added to recurring events and suggests Series Passes instead. A pass is one purchase that covers the series, which is a different product from a ticket to one evening.
• Modern Events Calendar lets you override Total Booking Limit and Tickets on one occurrence after you enable Edit Per Occurrence.
• Eventonomy writes a row per date and sends its one-day and one-hour reminders naming each date. For how RSVP counts and capacity work across dates, check the product page before you rely on them.

Ask four things of any plugin.

1. Is capacity counted per date or across the whole series?
2. When I cancel one date, what happens to the people who booked it?
3. When I reschedule the series, do bookings survive?
4. Does the attendee list let me export one date?

For paid events the questions get sharper because money is involved. Our guide to selling event tickets on WordPress covers fees, check-in and refunds, and it is worth reading before you put a price on a recurring series. Rules about refunds and sales are local, so check yours.

Do recurring events create duplicate content for search?

They can, because fifty dates of the same event can mean fifty near-identical pages. Search engines then have to guess which page matters, and none of them gets much attention. The fix is to decide which page you want to rank and make every other page point to it or add something real.

Three approaches work, and the right one depends on how you use the series.

• One page for the series. Show the next dates on a single series page. This suits a weekly call where every date is the same.
• One page per date, with real differences. Give each date its own topic, speaker or agenda in the title and description. Now they are different pages, not copies.
• Per-date pages with a canonical link to the series. A canonical link tells search engines which version is the main one. Some SEO plugins can set this per page.

Past dates need a policy too: keep them as an archive, redirect them to the series page or drop them from sitemaps. Modern Events Calendar has an option, “Show only one occurrence of this event”, so archives and shortcodes display only the next upcoming occurrence. That keeps list pages from filling with repeats of the same title.

Give each public date a clear title with the date or topic. Our post on running an events community on your own site explains why public event pages on your own domain are worth the effort.

How do you test a recurring event before you publish it?

Test the rule on a copy first, with dates that stress it: a clock change, a month end, a leap year, a cancellation and a booking. A series that looks right on the first three dates can still fail in month five.

Use this checklist. Run it on a staging site or with a private test event, then delete the test.

1. Generate the series and count it. Set a weekly rule with a known end. To confirm it worked, count the dates in the admin list against a paper calendar.
2. Cross a clock change. Pick a series that spans your region’s spring or autumn change. To confirm, check the shown time on each side of the change in the calendar, the event page, the reminder email and an exported calendar file.
3. Test the 31st. Use a monthly rule on day 31 for six months. To confirm, note which months have no date and decide whether that is acceptable.
4. Test the nth weekday. Use “second Tuesday” and “last Friday” if the plugin has them. To confirm, compare against a calendar for the next twelve months.
5. Cancel one date. Use the proper cancel tool. To confirm, check the list page, the single page, the calendar view and any feed, then restore it if the tool allows.
6. Change one date. Edit the title or time of one occurrence by the method your plugin documents. To confirm, check that the other dates are unchanged, or are changed if you meant that.
7. Change the whole series. Move the start time by an hour. To confirm, check that cancelled dates stay cancelled and that existing bookings are kept or handled the way you expect.
8. Book one date. Make a test RSVP or booking. To confirm, check that capacity changes only for that date, the confirmation names the date, and the reminder names the date.
9. Cancel a booked date. To confirm, check that the person is told and that the booking list shows what happened.
10. Check the end. Leave one series with no end. To confirm, find out how far ahead the plugin creates dates, and what extends it later. The Events Calendar says “never” means up to 60 months ahead. Eventonomy creates dates 12 months ahead by default and extends the horizon with a daily background job.
11. Check search and feeds. To confirm, open the sitemap and the calendar feed, and look at which dates are listed and which page carries the main title.
12. Check phone width. To confirm, open the calendar and a series page at 390 px wide and make sure the date list is readable and the cancel notices show.

How do you migrate a recurring series to another plugin?

Migrate the rule when you can and the dates when you cannot, and never delete the old events until the new series has been checked. Plugins store recurrence in different shapes, so a straight export and import of events often turns a series into plain, unrelated events.

Follow these steps.

1. List every series. Write down each rule in plain words, such as “every Tuesday at 7 pm New York time, ends in June”, plus its exceptions and its location. To confirm, you can read the list aloud and a colleague agrees with every line.
2. Export what you can. Save an export of your events and your attendee data. To confirm, open the file and check that the dates and time zones are present.
3. Decide per series: recreate or import. Recreating the rule in the new plugin keeps the series as a series. Importing dates gives you single events with no link between them. For a weekly series with years of history, a common approach is to import past dates as archive events and recreate the future rule fresh. To confirm, check that the new series generates the next date you expect.
4. Map the exceptions. Reapply cancelled dates with the new plugin’s own cancel or exception tool. To confirm, compare the future dates in both plugins side by side.
5. Move bookings with care. Past attendee records can be kept as an export. Future bookings are harder, because each plugin ties them to its own event records, so tell members and ask them to rebook if there is no safe import. To confirm, test a booking on the new site.
6. Set redirects. Old event URLs should point to the new pages. To confirm, open ten old links and check that each lands on the right place.
7. Run the checklist above on the new series before you announce it.
8. Switch off the old plugin last, after a few weeks, once nothing links to it and members have found their dates.

If you are moving the whole site’s look at the same time, change the theme as a separate step. The guide to changing your community theme without losing members or content explains the order, and the post on leaving the StellarWP stack covers a larger move that includes events.

Which approach fits a community site?

A community usually needs a few predictable series, such as a weekly call, a monthly meetup and a yearly conference, plus members who can see them, say yes and get a reminder. That favours a simple, well-tested rule over a rich pattern engine.

Our suggestion, as the makers of Eventonomy: start with the plain patterns, which cover weekly and monthly series with an interval, and cancel single dates when needed. If your schedule needs layered rules or per-date ticket changes, look hard at The Events Calendar or Modern Events Calendar, which document those tools in detail. If you want events to sit inside a community with profiles and activity on a Reign site, Eventonomy is built to run beside the rest of the Wbcom products, and our post on running community events on a Reign site walks through it.

Questions people ask

How do I make an event repeat every week in WordPress?

Create the event with its first date, then switch on repeating and choose weekly with an interval of 1. Set how the series ends, by date or by number of occurrences. Then check the generated dates against a calendar before you publish.

Can I change just one date in a recurring event?

It depends on the plugin. The Events Calendar edits an instance through its Series and a “This event” choice. Events Manager treats each recurrence as its own event, so editing one changes only that one. Eventonomy edits a series as a whole and cancels single dates, so a date that must differ becomes a separate one-off event.

Why does my recurring event show the wrong time after the clocks change?

The event was probably stored with a fixed offset from UTC, or without a named time zone. Clocks moving by an hour then shifts the displayed time. Set the event to a named zone, such as a city, and test the dates on both sides of the change.

How do I skip a holiday in a repeating event?

Use the plugin’s own exception or cancel tool for that date. The Events Calendar has exceptions, Modern Events Calendar has an Exceptional Days module, and Eventonomy has a Cancel this date action. Avoid deleting the row by hand, because it may come back when the series is recomputed.

What is an RRULE?

An RRULE is the repeat rule in the iCalendar standard, RFC 5545. It combines a frequency such as weekly or monthly with optional parts like an interval, a weekday and an end. Many calendar tools use it, which is why a stored rule travels better between systems than a list of dates.

Reign is the theme that ties these pieces together on one site. It styles the calendar, event pages, community and courses so they look like your brand, and it works with Eventonomy without add-ons. See the Reign theme page for features and demos, or try the BuddyNext live demo to see a working community first.