# Event Lifecycle in RUFUS Events App RUFUS Events App shows different public information depending on the event dates, the race status, and the data published from RUFUS Race Manager. This lifecycle allows the app to display the right information at the right time: before the event, while races are live, after results are published, and during the short post-event window when live features may still be available. ## Public Event Window The public event window defines when an event should behave as active or live in RUFUS Events App. This window is configured in RUFUS Cloud using: * Event period start * Event period end These dates are used to control live behavior, automatic updates, fan subscriptions, and event availability. For best results, every public event should have both event period dates configured in RUFUS Cloud. ## Event Start Date Fallback RUFUS Events App can also use the event start date from RUFUS Race Manager. This date is mainly used as a fallback for older or incomplete publications where the event period has not been configured in RUFUS Cloud. For modern event publications, the event period start and event period end should be considered the main public lifecycle dates. ## When an Event is Considered Live An event is considered live when at least one race is actively processing passings and the event is inside its valid public event window. In practical terms, this means: * The event period has started. * The event is not more than 24 hours past the event period end. * At least one race is currently processing passings. If the event does not have a usable public date window, the app will not show the event as live, even if one of the races is processing passings. ## Race Live State Each race has its own live status. A race is considered live when that specific race is processing passings and the event is inside its valid public event window. This live status comes from the race configuration published from RUFUS Race Manager. Progress or results data may include additional information, but the race live state is controlled by the race itself. This makes the live status more reliable, especially for events with multiple races, different start times, or several publication types. ## Before the Event Before the event period starts, RUFUS Events App can display public event information and participant data if these have been published and enabled. Depending on the event configuration, visitors may be able to: * View event information * Search the participant list * Check athlete registration details * Access race information * Prepare for fan notifications, when available Live behavior is not active before the event period starts. ## During the Event During the public event window, RUFUS Events App can behave as a live event page. Depending on what has been published, visitors may be able to access: * Live leaderboards * Race progress * Race clock * Male and female leaders * Checkpoint progress * Predictive tracking map * Athlete search * Team cups * Personalized athlete result pages When new data is published, the app can update internally without requiring visitors to manually reload the page. ## Race Progress Visibility Race Progress is shown when a race has published progress data. This means that Race Progress can be visible while the race is live, but it can also remain visible after the race has finished as historical or final progress information. The live race clock is shown only while the race is currently live. If the race is no longer live, the progress view can still remain available, but live-only clock indicators are hidden. ## Map and Predictive Tracking Visibility The Map view is shown only when predictive tracking can be calculated correctly. For the Map option to appear, the race must have: * Published race progress data * A valid published course * A route with enough course points * Participant tracking data that can be projected onto the course If the race does not have a valid course, the Map option is hidden. This prevents visitors from seeing an incomplete or inaccurate tracking view. ## Leaderboard Visibility The Leaderboard view is shown when the selected race has published finished results. If a race has progress data but no finished results yet, the Leaderboard option may be hidden and the app can show Race Progress instead. This allows events to publish progress-only information during the race, and then show leaderboards once result data becomes available. ## After the Event After the event period ends, RUFUS Events App can continue to show event information, results, progress data, athlete result pages, team cups, and diplomas when available. Live behavior can remain available for up to 24 hours after the event period end. This grace window helps support events that finish late, multi-day events, delayed result publication, or final updates shortly after the race. More than 24 hours after the event period end, live behavior is suppressed. The event can still remain publicly accessible, but it is no longer treated as live. ## Fan Subscriptions Fan subscription notices and clickable athlete rows are shown when fan-facing notifications are active for the event. Subscriptions may be available when: * Fan notifications are enabled. * The notification applies to the selected race or to all races. * The subscription window is still active. The subscription window normally remains available until 24 hours after the event period end. If the event period is not configured, RUFUS Events App may use the event start date as a fallback. This keeps fan subscriptions available during the public live window and avoids ending them too early for events with multiple races or multi-day schedules. ## Automatic Updates and Polling RUFUS Events App checks for new published data automatically. The app first checks lightweight publication metadata. If the metadata has changed, it then downloads the updated publication data. This keeps the app efficient while still allowing visitors to receive fresh information during the event. The update behavior follows the event lifecycle: * Before the event starts, the app checks less frequently. * During the event window, the app checks for updates. * While a race is live, the app checks more frequently. * After the event period ends, live update behavior is reduced. * More than 24 hours after the event period end, live behavior is disabled. Visitors do not need to manually refresh the page to receive new published data during the live event experience. ## Recommended Publication Model For consistent behavior in RUFUS Events App: * Configure event period start and event period end in RUFUS Cloud for every public event. * Use the event start date from RUFUS Race Manager only as a fallback lifecycle date. * Start and stop race passing processing correctly in RUFUS Race Manager. * Publish participant information before race day. * Publish race progress independently from results when visitors should follow the race live. * Publish race results when leaderboards and final rankings should be available. * Publish race courses when the Map and Predictive Tracking views should be available. * Keep event visibility and publication settings updated in RUFUS Cloud. Using the event lifecycle correctly ensures that RUFUS Events App shows the right sections at the right time, providing a clear before-race, live-race, and post-race experience for visitors. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.runonrufus.com/rufus-event-app/getting-started/event-lifecycle-in-rufus-events-app.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.