Events hosting for calendars that repeat for years.
A weekly event is one post to you and thousands of dated instances to the database. Calendars get slow because of the ones nobody typed.
One event, a thousand dates.
Recurrence is the thing that makes an events site heavy, and it is invisible in the admin.
Recurring series that stay queryable
A weekly event running two years is thousands of occurrences the calendar must filter by date. Those lookups are indexed so opening next March costs the same as opening this week.
Times that are right everywhere
Events have a timezone and visitors have another. Dates are stored and compared in a way that survives daylight saving, so a listing does not drift by an hour twice a year.
Feeds served from cache
Calendar subscriptions and iCal exports are polled by software on a timer. They are cached and revalidated, so a hundred subscribed calendars are not a hundred renders.
Month views that do not scan everything
A month grid asks for every occurrence inside a date window. Given the right indexes that is a range lookup rather than a walk through the whole series table.
Undo a broken series edit
Editing a recurring event can rewrite every future instance at once. Daily backups mean getting that wrong is recoverable rather than a manual repair.
The events nobody entered by hand.
An organiser sees a dozen events. The database sees every occurrence of every series, and it is the second number that decides how the calendar performs.
- Occurrence lookups indexed by date
- Feeds cached and revalidated cheaply
- Times stored so daylight saving cannot shift them
- Series edits recoverable
Next March opens as fast as this week.
The measure for a calendar is whether moving forward a few months feels the same as loading the current view, because that is what visitors do constantly.
What we change for The Events Calendar
Recurrence turns a small content set into a large one, and every row here is about querying the large one.
| Setting | What we do | Why |
|---|---|---|
| Occurrence indexing | Indexed on start and end date | Every calendar view is a date-range question against a table that recurrence has already multiplied by hundreds. |
| Feed caching | iCal and subscription feeds cached with validators | Calendar clients poll on a timer, so those URLs are requested far more often than any page on the site. |
| Timezone storage | Kept with the event rather than derived at display | Deriving a time at render means a daylight saving boundary silently moves listings by an hour twice a year. |
| Series regeneration | Run as a batch with its own limits | Changing a recurring event's schedule rewrites every future occurrence, which is far more work than a page request allows. |
| Past occurrences | Kept but excluded from default queries | An archive of finished events is worth keeping and worth never scanning on a view of next month. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why is my calendar slow with only a few events?
Do you support ticketing add-ons?
Will event times be right for international visitors?
Can visitors subscribe to the calendar?
Keep the calendar quick all year.
Move the events site across - migration is free, every series included.