This page summarizes how quickly edits published in Beatrix appear on YSM and Yale Medicine websites, and what caches or indexers can delay visibility. Times below assume normal operations; backlogs or outages can extend delays.
At-a-Glance: Typical Update Times
Entity / Surface | Where It Appears | Typical Time to Appear | Primary Factors | Notes |
|---|---|---|---|---|
CMS Content Pages (T4/YM static pages) | medicine.yale.edu sites | Seconds to a few minutes | NGINX cache (3 min serve-stale), in‑app caches. | Direct page updates are cache‑busted on publish; residual NGINX cache may briefly serve stale content until purge completes and warming repopulates. |
News Articles (detail pages) | YSM, YM | Seconds to a few minutes | T4 Solr apply delay (~1 min); NGINX cache | Automated cache busting enabled; Solr must reflect the change before listings/related blocks refresh. |
News Listings (widgets/landing pages) | YSM, YM | Seconds to a few minutes | Solr indexing lag; listing caches via NGINX | Listings refresh after Solr updates; landing pages may be purged by dependencies when articles change. |
Events (detail pages) | YSM, YM | Seconds to a few minutes | T4 Solr apply delay; NGINX cache | Automated cache busting enabled; time-based expirations also influence visibility for past/future states. |
Events Listings (calendars) | YSM, YM | Seconds to a few minutes | Solr indexing lag; NGINX cache | Future/past filters can make items appear/disappear as dates roll over. |
Clinical Trials (detail) | YSM, YM | Seconds to a few minutes | T4 Solr apply delay; NGINX cache | Automated cache busting enabled; status changes (“Not Accepting Volunteers”) propagate with the same lag. |
Clinical Trials (search/listing pages) | YSM, YM | ~1–3 minutes | Solr indexing lag; NGINX cache | Search filters and text search refresh post-index update. |
Clinical Trials (Changes made in OnCore | YSM, YM | Next business day | Sync with OnCore | |
Profiles (YSM People; YM Specialists) | YSM, YM | Seconds to a few minutes | Granular indexing; NGINX cache; upstream syncs | YSM help text cites “within twenty minutes.” Many edits appear much faster under normal load. |
Profiles (Workday, Talend data like Business Titles, Appointments, Board Certifications, etc.) | YSM, YM | Next business day | Synch with HR systems | |
Media assets (images/video URLs) | All sites | Seconds to a few minutes | Cloudinary CDN (long TTL), NGINX for metadata endpoints | Derived assets are CDN‑cached up to 1 year; URL changes are immediate, asset replacements may be cached until a new URL/version is referenced. |
Navigation (side/footer) | YSM, YM | ~10 minutes | Navigation Service in‑memory cache (10 min); NGINX | Structural nav changes may take up to 10 minutes without manual purge. |
Search results (site search) | YSM | ~1–3 minutes | Granular Solr updates for most types | Most primary entities are updated granular rather than requiring a full re-index. |
Platform- and Cache-level Behavior
T4 and YM2 automated cache busting
T4: Automated cache busting covers Profiles, Events, News, Clinical Trials, Media items, basic Organization info, and CMS Pages. A ~1 minute wait for Solr to apply updates commonly gates visibility on pages using listings or search-driven components.
YM2: Automated cache busting covers Specialists, Fact Sheets, News, SDL Pages, and basic Organization info. Detail pages are covered; listing/recommendations driven by YM2 Search and CCM are harder to capture automatically.
Cache warming is enabled post-purge to repopulate caches; during heavy load, some warming URLs may be discarded if likely already warm.
Key caches and indexers that influence timing
NGINX cache: 3 minutes TTL with “serve stale” semantics. Global and per-URL purges are issued by the Cache Management system; content can appear instantly after a purge/warm completes, otherwise the 3-minute window applies.
T4: Granular updates with an observed ~1 minute apply delay for most content powering listings/search.
YM2: Granular indexing typically runs every 15 minutes for some collections; many detail surfaces are direct-feeds and cache-busted.
Pages/components: 5 minutes (T4 default).
settings.xml: 10 minutes (T4).
security.xml: 5 minutes (T4), 30 minutes (YM2).
Navigation Service: 10 minutes.
Azure CDN (front-end assets): 1 year TTL; cache busting via file name hashing.
Cloudinary (media): up to 1 year TTL for original and derived assets; new URLs/versioned transforms reflect immediately.
Entity-specific Details and Scenarios
CMS Content Pages (SDL/T4)
On publish: page-level cache bust issues invalidation; most changes appear within seconds once the purge command completes and warming refills caches.
If a page pulls in SDL resources like settings.xml or navigation: those components may retain older values up to their cache window (typically 10 minutes for settings; 10 minutes for navigation) unless a purge is triggered.
News
Detail pages: cache-busted on publish; Solr index applies within ~1 minute to support related content and cross-page dependencies.
Listings (widgets/landing pages): listings refresh after Solr updates; typical 1–3 minutes end-to-end including NGINX.
Preview: historically, rapid (seconds) but repeated rapid publishes within minutes could cause 5+ minute variability; this was optimized in late 2024 to 5–10 seconds in normal preview flows.
Events
Detail pages: same pattern as News; automated bust + ~1 minute Solr apply.
Listings: typical 1–3 minutes; date rollovers and expiry rules may also remove/insert events on schedule.
Clinical Trials
Detail pages: automated bust + ~1 minute Solr apply. Status changes (e.g., Closed to Accrual) flow through the same path.
Search/listings: typical 1–3 minutes given Solr apply and NGINX window.
Org-based trials: resyncs may take several minutes for large orgs; after sync, website visibility follows the same listing/update cycle above.
Profiles and People Listings
Profile edits generally propagate “within twenty minutes”; under light load, many changes appear sooner due to granular indexing and automated busting.
People listings across sites reflect profile updates after indexing and cache clearing; end-to-end commonly 1–10 minutes, up to ~20 minutes cited in user help.
Policy note: external/non-employee profiles no longer receive public details pages; listings still update on the same cadence.
Organizations
Basic organization info is covered by automated cache busting; expect 1–3 minutes for most page updates driven by org fields.
Breadcrumbs, navigation labels, and footer data may be gated by Navigation Service caches (≈10 minutes) unless purged.
Media
New assets: once a page references the Cloudinary URL, the asset loads immediately if not cached; derived transformations are cached by Cloudinary with long TTLs.
Asset replacements: if the URL stays the same, CDN caches may continue serving older bytes; best practice is to reference versioned URLs for truly immediate swaps.
What Can Extend Delays
Search/index apply time: T4’s ~1 minute Solr apply is a hard minimum for most listing/search-driven surfaces.
NGINX serve-stale: without a purge, stale responses can be served beyond the nominal 3-minute TTL during upstream blips.
Message queue backlogs: bulk syncs (e.g., Dimensions, Workday) can flood Service Bus; user edits then wait behind sync messages, causing multi-hour delays in rare cases. Workarounds include pausing syncs and reloading feeds, or targeted module reloads.
Navigation/SDL resource caches: 5–10 minute in‑app cache windows can gate site‑wide settings and nav updates.
Best Practices to See Changes Faster
Prefer preview checks, then publish live once confirmed.
Allow ~1–3 minutes for listing/search-driven surfaces after publishing details.
If a change affects navigation labels or global settings, allow up to 10 minutes or request a targeted purge from the Web Services team.
For urgent visibility during known backlogs, coordinate with Web Services to temporarily prioritize UI updates or issue targeted reloads.
When replacing media, update the asset URL (versioned path) to bypass CDN caches immediately.
FAQ
Reference Details
Automated Cache Busting Status (T4/YM2 coverage and Solr wait): https://ysmweb.atlassian.net/wiki/spaces/TECH/pages/2367225916/Automatic+Cache+Busting+Status
Caching Components (NGINX 3m + serve-stale; in‑app cache TTLs; Solr cadence; CDNs): https://ysmweb.atlassian.net/wiki/spaces/TECH/pages/2115960865/Caching+components
Cache management problem/overview and operational nuances: https://ysmweb.atlassian.net/wiki/spaces/TECH/pages/2559115274/Cache+management+problem and https://ysmweb.atlassian.net/wiki/spaces/TECH/pages/2560393233/Cache+Management+overview
YSM Help (Profiles “within twenty minutes” user guidance): https://ysmweb.atlassian.net/wiki/spaces/HELP/pages/1702395932/Edit+a+Profile
Preview performance note (news preview optimization): Technical Release Notes - Nov 8, 2024