1 · Is the change saved in Google?

Obvious, and worth thirty seconds. Recurring events in particular have an “this event / this and following / all events” prompt, and it is easy to pick a narrower option than you meant. Check the calendar on a different device than the one you edited on.

2 · Is the change in the feed?

Open your calendar's secret .ics address in a browser tab and save the file. Search it for the event. If it is not there, nothing after this point matters — the problem is between Google's editor and Google's export.

This is more common than it sounds, because Google does not regenerate the file immediately. A published .ics can lag the calendar by hours. If your change is recent, this is the most likely answer and the fix is patience.

3 · Is your site fetching at all?

Find the plugin's screen showing when it last fetched. If it says days ago, the sync has stopped and the cause is scheduling — see the next check. If it has no such screen, that is worth knowing in itself.

4 · Is WordPress cron running?

WordPress's scheduler fires when somebody loads a page, not on a clock. A quiet site runs its scheduled jobs erratically, and a very quiet site barely runs them at all.

The fix is to disable the built-in behaviour with define( 'DISABLE_WP_CRON', true ); in wp-config.php and have your host call wp-cron.php on a real schedule. Most hosts offer this; several do it already.

5 · Is something caching the page?

If the sync ran and the database has the new event but the page still shows the old one, you are looking at a cached page rather than a sync problem. Purge your caching plugin and your CDN, and check in a private window. Page caches with long lifetimes are a genuine hazard for anything time-sensitive.

6 · Did the URL stop working?

Secret calendar addresses can be reset in Google, which invalidates the old one instantly. If somebody reset it — a security tidy-up, or a shared account being cleaned — your site is fetching a URL that now returns an error. A well-built plugin shows the error; a badly built one shows an empty calendar. Fetch the URL yourself and see what comes back.

The pattern

Five of these six are invisible unless the plugin tells you. The single most useful property in a calendar that syncs is not how fast it fetches — it is whether you can tell, in ten seconds, when it last worked and what went wrong. Everything on this page is quick once you know that; without it, every cause looks the same from the front end.