Fortnite players ask the same question every few weeks: when does the current season actually end, and what happens the moment it does? Chapter 7 Season 4, “Override,” launched on August 20, 2026, and its reported wind-down date is November 1, 2026, which means the countdown to the next season is already running. Instead of refreshing a wiki page every morning, this tutorial walks through building your own live countdown widget, a small embeddable component that pulls real season data, falls back gracefully when the data source is down, and drops into any website with a two-line snippet. By the end you will have a working, deployable project you can point at your own blog, Discord bot dashboard, or fan site.
What “Next Fortnite Season” Actually Means Right Now
Before writing a line of code, it helps to know what data you are actually chasing. Epic Games does not publish a fixed release calendar for Fortnite seasons, so “when is the next Fortnite season” is a moving target that shifts as the current one gets extended or cut short. As of September 29, 2026, Chapter 7 Season 4 is the active season, and Epic has not yet confirmed the exact launch date, name, or Battle Pass lineup for Chapter 7 Season 5. That gap between “current season end date” and “next season confirmed date” is exactly what a good countdown widget needs to model, because it has to handle both a known countdown and an unknown one without breaking.
There is also a competitive calendar layered on top of the seasonal one. The 2026 Fortnite Global Championship ran September 26-27 in Antwerp, Belgium, with a reported $2 million prize pool, and FNCS Solos kicked off its first qualifier September 28-29 across seven regions (NAC, NAW, EU, Asia, Brazil, Middle East, and Oceania). Later FNCS Solos qualifiers are scheduled for October 5-6 and October 10-11, with heats October 17-18, a Last Chance stage October 19-20, and finals October 26-27. Those dates matter for a countdown widget because a season transition rarely happens mid-tournament, so your widget’s fallback logic should treat scheduled esports windows as a signal, not just decoration.
Doing the arithmetic on the two confirmed dates gives a useful sanity check for your own widget: Override’s run from August 20 to its reported November 1 wind-down spans 73 days, a little over ten weeks. That number is not something to hardcode as a universal rule, since Fortnite seasons have varied in length before, but it is a reasonable ballpark to keep in mind when you are eyeballing whether a fallback date you typed in looks plausible or whether you fat-fingered a digit.
The widget you are about to build does not try to predict Epic’s internal roadmap. It reads whatever season end date is currently published, counts down to it, and swaps to a “new season detected” state the moment the data source reports a change. That is a more honest approach than hardcoding a guessed date, and it is also the only approach that keeps working after Chapter 7 Season 5 actually ships.
Why Build a Widget Instead of a Bot or Backend Tracker
There is more than one way to track a Fortnite season transition. A Discord bot can ping a channel when something changes. A backend service with a database can log every season’s start and end date for historical analysis. Both are valid, but they solve a different problem than the one covered here. A bot only reaches people already in your server, and a database-backed tracker needs a server process running around the clock, plus somewhere to host it.
A countdown widget solves the “show this to anyone who lands on a web page” problem. It ships as static files, so hosting costs stay near zero, and it works the instant a visitor opens the page rather than requiring them to join a server or subscribe to alerts. The trade-off is that a client-side widget cannot easily notify someone who is not currently looking at the page, which is exactly the gap a bot fills. If you want both, nothing stops you from running the widget on your site and a separate bot for push-style alerts, since the fetch-and-fallback pattern in this tutorial works equally well inside a scheduled server job.
One more advantage worth calling out: because the widget defined here is a standard Web Component, it behaves like any other HTML element. You can drop it into a static site generator, a React tree, or a plain WordPress post, and it will render identically in all three without any adapter code. That portability is the main reason this tutorial builds the countdown as a Custom Element rather than a framework-specific component.
Prerequisites: Tools and Versions You Need
This build uses plain JavaScript and native browser APIs, so there is no framework lock-in. You can drop the finished widget into a React app, a static HTML page, or a WordPress theme without modification. Here is what to install before starting.
| Tool | Version | Why You Need It |
|---|---|---|
| Node.js | 20.x LTS or newer | Local dev server and build tooling |
| npm | 10.x or newer | Installing dependencies, running scripts |
| A code editor | Any (VS Code recommended) | Writing and debugging the widget |
| Git | 2.40 or newer | Version control and deployment |
| Fortnite-API.com account | Free tier | Optional API key for higher rate limits |
| Cloudflare account | Free tier | Hosting the finished widget (Step 11) |
| A modern browser | Chrome 115+, Firefox 115+, Safari 16+ | Testing Web Components and Shadow DOM |
Note that Fortnite-API.com is a community-run project, not an official Epic Games service. It mirrors publicly available season and shop data and is widely used by fan tools, but it can occasionally lag behind Epic’s own client by a few hours after a big update. That is precisely why Step 6 covers a local fallback, so your widget never shows a blank screen just because a third-party API hiccups.
Step 1: Scaffold the Project Folder
Create a clean project directory with a minimal structure. You do not need a bundler for this build since browsers now support ES modules and Custom Elements natively. Keeping the tooling minimal also means the finished widget has no build step for site owners who just want to copy a script tag, which lowers the friction for anyone who wants to embed it on their own page.
mkdir fortnite-season-countdown
cd fortnite-season-countdown
npm init -y
mkdir src
touch src/countdown-widget.js src/index.html src/styles.cssAdd a lightweight local server so you can test in a real browser context instead of opening the file directly (which blocks fetch calls under the file:// protocol in most browsers).
npm install --save-dev serve
npx serve srcStep 2: Fetch Live Season Data
The core data call retrieves the current season’s end timestamp. Wrap it in a function that returns a normalized object so the rest of your widget never has to think about the raw API shape. Fortnite-API’s documentation lists the available endpoints; the BR news endpoint used below is one of the few that does not require an API key for basic requests.
async function fetchSeasonData() {
const response = await fetch('https://fortnite-api.com/v2/news/br', {
headers: { Accept: 'application/json' }
});
if (!response.ok) {
throw new Error(`Fortnite-API responded with ${response.status}`);
}
const payload = await response.json();
return {
seasonName: payload.data?.motds?.[0]?.title ?? 'Unknown Season',
fetchedAt: Date.now()
};
}In production you will likely combine this with a maintained end-date value, since Fortnite-API’s free endpoints do not always expose a machine-readable season end timestamp. Step 6 shows how to pair a live fetch with a manually maintained date so the countdown stays accurate even when the API only confirms that a season is still active.
Step 3: Write the Countdown Calculation Logic
Countdown math looks simple until you hit daylight saving transitions and leap seconds. Keep everything in UTC internally and only convert to the viewer’s local time zone at render time.
function getTimeRemaining(targetIsoDate) {
const total = Date.parse(targetIsoDate) - Date.now();
if (total <= 0) {
return { expired: true, days: 0, hours: 0, minutes: 0, seconds: 0 };
}
return {
expired: false,
days: Math.floor(total / 86400000),
hours: Math.floor((total % 86400000) / 3600000),
minutes: Math.floor((total % 3600000) / 60000),
seconds: Math.floor((total % 60000) / 1000)
};
}Using Date.parse on an ISO 8601 string avoids the classic bug where a date string like "2026-11-01" gets parsed in local time on one browser and UTC on another. Always store and pass full ISO timestamps with an explicit offset, such as 2026-11-01T14:00:00Z. This single habit eliminates most of the "the countdown is off by a few hours" bug reports you would otherwise get from users in different time zones.
It is worth writing a quick unit test around this function before moving on, since every later step depends on it returning consistent values. A simple assertion that feeds in a date one hour in the future and checks that hours equals 0 and minutes is close to 59 catches most off-by-one errors early, before they get buried inside the rendering logic.
Step 4: Build the Custom Element with Shadow DOM
Wrapping the widget in a Web Component means any site owner can embed it without your CSS colliding with theirs. Shadow DOM isolates the styles completely, which matters a lot once you start distributing the widget to sites you do not control. Without it, a host page's global CSS reset or a conflicting class name could silently break your layout.
class SeasonCountdown extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
this.state = { days: 0, hours: 0, minutes: 0, seconds: 0 };
}
connectedCallback() {
this.render();
this.timer = setInterval(() => this.tick(), 1000);
this.loadData();
}
disconnectedCallback() {
clearInterval(this.timer);
}
async loadData() {
const target = await resolveTargetDate();
this.targetDate = target;
}
tick() {
if (!this.targetDate) return;
this.state = getTimeRemaining(this.targetDate);
this.render();
}
render() {
const { days, hours, minutes, seconds } = this.state;
this.shadowRoot.innerHTML = `
${days}d${hours}h
${minutes}m${seconds}s
`;
}
}
customElements.define('season-countdown', SeasonCountdown);The resolveTargetDate function referenced above ties together the live fetch from Step 2 and the fallback logic from Step 6, so the element never renders before it knows which date to count toward.
Step 5: Style the Widget Without CSS Collisions
Because the styles live inside the shadow root, you can write plain CSS without prefixing every class name. Keep the footprint small so the widget loads fast on mobile.
const widgetStyles = `
.countdown {
display: flex;
gap: 0.5rem;
font-family: system-ui, sans-serif;
font-variant-numeric: tabular-nums;
}
.countdown span {
background: #111;
color: #fff;
padding: 0.4rem 0.6rem;
border-radius: 6px;
font-size: 0.9rem;
}
`;Using font-variant-numeric: tabular-nums prevents the digits from jittering side to side every second as the width of "1" and "8" differ slightly in most fonts, a small detail that makes a countdown feel noticeably more polished.
Step 6: Add a Local Fallback for API Outages
Third-party APIs go down, rate-limit you, or simply lag behind a real-world announcement. Your widget should never show a blank box when that happens. Maintain a small fallback file with the last confirmed season end date and treat it as the source of truth until the live fetch succeeds.
const FALLBACK_SEASON_END = '2026-11-01T14:00:00Z';
async function resolveTargetDate() {
try {
const data = await fetchSeasonData();
return data.confirmedEndDate ?? FALLBACK_SEASON_END;
} catch (err) {
console.warn('Falling back to cached season date:', err.message);
return FALLBACK_SEASON_END;
}
}Update FALLBACK_SEASON_END whenever Epic confirms a new date. Treat this constant as the single place you edit when the next Fortnite season gets an official release window, so you are not hunting through render logic every time the calendar shifts.
Step 7: Cache API Responses in localStorage
Hitting the API on every page load adds latency and burns your rate limit. Cache the response for a short window in the browser's localStorage, since season end dates rarely change more than once a day even during a live transition. This also means a returning visitor gets an instant render on their second page load instead of waiting on a network round trip.
const CACHE_KEY = 'fn-season-cache';
const CACHE_TTL_MS = 15 * 60 * 1000;
function readCache() {
const raw = localStorage.getItem(CACHE_KEY);
if (!raw) return null;
const parsed = JSON.parse(raw);
if (Date.now() - parsed.cachedAt > CACHE_TTL_MS) return null;
return parsed.data;
}
function writeCache(data) {
localStorage.setItem(
CACHE_KEY,
JSON.stringify({ data, cachedAt: Date.now() })
);
}A 15-minute TTL keeps the widget responsive without hammering Fortnite-API's free tier. If you expect heavy traffic, raise the TTL to an hour and rely on the countdown math itself (which needs no network call) to keep ticking accurately between refreshes.
Step 8: Handle Time Zones for a Global Audience
Season transitions happen at a fixed UTC moment, but your viewers are scattered across every time zone. Rather than displaying raw UTC, use the browser's own Intl.DateTimeFormat to show a localized date alongside the ticking counter.
function formatLocalDate(isoDate) {
return new Intl.DateTimeFormat(navigator.language, {
dateStyle: 'medium',
timeStyle: 'short'
}).format(new Date(isoDate));
}This automatically renders in each visitor's own locale without you maintaining a lookup table. For reference, here is how a single UTC transition maps to a handful of common regions, useful when you are manually sanity-checking the widget's output.
| Region | UTC Offset | Example Local Display |
|---|---|---|
| US East (New York) | UTC-4 | 10:00 AM |
| US West (Los Angeles) | UTC-7 | 7:00 AM |
| UK (London) | UTC+1 | 3:00 PM |
| Central Europe (Berlin) | UTC+2 | 4:00 PM |
| Japan (Tokyo) | UTC+9 | 11:00 PM |
| Australia (Sydney) | UTC+11 | 1:00 AM (+1 day) |
Step 9: Auto-Detect Season Rollover
When the countdown hits zero, do not just freeze at 0d 0h 0m 0s. Trigger a re-fetch and swap the widget into a "checking for new season" state, since Epic's maintenance window typically lasts a few hours.
tick() {
if (!this.targetDate) return;
this.state = getTimeRemaining(this.targetDate);
if (this.state.expired && !this.rolloverTriggered) {
this.rolloverTriggered = true;
this.loadData();
}
this.render();
}The rolloverTriggered flag stops the widget from spamming the API every second once the timer hits zero. Reset it only after a successful fetch returns a new target date further in the future than the previous one. It is worth adding a small backoff here too: instead of refetching every single second while waiting for a rollover to resolve, space the retries out to once every thirty seconds. Season transitions typically take Epic a few hours of maintenance to complete, so a tighter polling interval only burns through your rate limit without getting you fresher data any faster.
Step 10: Generate a Copy-Paste Embed Snippet
The whole point of building this as a Custom Element is that embedding it anywhere takes two lines. Bundle your script and document the snippet so other site owners can drop it in without reading your source code.
<script type="module" src="https://yourdomain.com/countdown-widget.js"></script>
<season-countdown></season-countdown>Because the widget attaches its own Shadow DOM and manages its own timer, there is nothing else for the embedding page to configure. That is a meaningful difference from an iframe-based embed, which requires the host page to manage sizing and cross-origin messaging.
Step 11: Deploy the Widget to Cloudflare Pages
Cloudflare Pages' free tier is enough to host a static widget script with generous bandwidth and a built-in CDN, which matters if your embed gets picked up by other sites and traffic spikes without warning.
npm install -g wrangler
wrangler login
wrangler pages deploy src --project-name=fortnite-season-countdownWrangler prints a live URL once the deploy finishes. Point your embed script tag at that URL, and Cloudflare's edge network handles caching and TLS for you at no extra cost on the free plan.
Step 12: Cross-Browser and Mobile Testing
Custom Elements and Shadow DOM are supported in every evergreen browser, but you should still verify on real devices before calling the project done. Check three things specifically: that the timer keeps ticking after the phone screen locks and unlocks, that the widget survives a tab going to the background for several minutes without drifting out of sync, and that text does not overflow on narrow 320px-wide viewports.
A quick way to catch drift bugs is to compare the rendered countdown against a server-calculated value every few minutes. If they disagree by more than a couple of seconds, the culprit is almost always setInterval drift, and switching to a requestAnimationFrame-driven loop with a wall-clock recalculation on every tick fixes it.
Test with a throttled network connection too. Chrome DevTools' "Slow 3G" preset is useful here, since it simulates exactly the kind of delayed API response the fallback logic in Step 6 is meant to handle. If the widget still shows a spinner or a blank box after five seconds on a throttled connection, that is a sign the fallback branch is not firing correctly, usually because the fetch call is missing a timeout and is just waiting indefinitely for a response that never comes. Wrapping the fetch in Promise.race against a short timeout promise is a simple fix that keeps the fallback path reliable under bad network conditions.
Finally, run the widget through a basic accessibility check. Screen readers announce the countdown text as it updates every second unless you scope the live region correctly, which gets noisy fast. Set aria-live="off" on the countdown container and instead expose a single, less frequently updated summary (for example, updated once a minute) inside an aria-live="polite" region for assistive technology users, so they get the same information without a stream of interruptions.
Example Output
Once deployed, the widget renders a compact four-box display like this in the browser console output during testing:
{ days: 33, hours: 6, minutes: 12, seconds: 47, expired: false }
Rendered: 33d 6h 12m 47s
Local display: "Nov 1, 2026, 10:00 AM" (US Eastern)When the countdown expires and a rollover check runs, expect a console line similar to Falling back to cached season date: Fortnite-API responded with 503 if the API happens to be under heavy load during the actual transition window, which is common in the first hour after a season change.
Common Pitfalls When Building a Season Countdown Widget
- Parsing dates without a timezone offset. A string like "2026-11-01" gets interpreted as local midnight in some engines and UTC midnight in others, which can shift your countdown by several hours depending on the visitor's browser.
- Polling the API every second. Only the countdown math needs to run every second. Network calls should be limited to the cache TTL window or you will hit rate limits fast.
- Forgetting to clear the interval. If
disconnectedCallbackdoes not clear the timer, removing the widget from the DOM leaks a running interval that keeps firing in the background. - Hardcoding a single time zone in the display. A countdown widget aimed at a global audience that only shows US Eastern time will frustrate players in Europe, Asia, and Oceania who have to do the math themselves.
- Assuming the API and the fallback date always agree. When Epic delays a season, the fallback constant can go stale faster than expected. Build a habit of checking it against official channels whenever you see the countdown hit zero without a new season actually appearing.
- Skipping the expired state entirely. A countdown that just shows negative numbers after the target date passes looks broken. Always branch into a distinct "checking for update" UI state.
- Treating the widget as a single point of truth without an update path. Season dates change, sometimes with only a day or two of notice. If the fallback constant lives buried inside a minified bundle rather than a clearly labeled configuration value, you will forget where to update it the next time Epic shifts a date.
Most of these pitfalls share a common thread: they show up only under conditions that are easy to skip during quick manual testing, a stale cache, a network hiccup, a visitor in an unusual time zone. Building the fallback and cache-clearing logic in from the start, rather than bolting it on after a bug report, is what keeps this kind of widget reliable once real traffic starts hitting it.
Troubleshooting Guide
Most issues you will run into fall into one of three buckets: a date parsing mistake, a caching problem, or a Shadow DOM scoping issue. The table below covers the specific symptoms most commonly reported when developers build a version of this widget for the first time, along with the fastest way to confirm and fix each one.
| Symptom | Likely Cause | Fix |
|---|---|---|
| Widget shows "NaN" everywhere | Target date failed to parse | Confirm the ISO string includes a "Z" or explicit offset |
| Countdown freezes at a fixed number | Interval was never started or got cleared early | Check connectedCallback is firing and the element is actually in the DOM |
| Styles leak into the host page | Not using Shadow DOM, or attaching styles outside shadowRoot | Move all CSS inside the <style> tag rendered in the shadow root |
| Fetch calls fail with CORS errors | Testing over file:// protocol | Serve the page with npx serve or another local HTTP server |
| Cached data never refreshes | TTL set too high or clock skew on the client device | Lower CACHE_TTL_MS and verify Date.now() looks correct in devtools |
| Widget doubles up after a hot reload | customElements.define called twice | Guard the definition with a check for an existing registration |
| Time shown is off by exactly one hour | Daylight saving transition on the viewer's device | Rely on Intl.DateTimeFormat instead of manual offset math |
| Rate limit errors (HTTP 429) from Fortnite-API | Too many uncached requests, often from missing an API key | Register a free Fortnite-API key and increase the cache TTL |
| Embed breaks inside a WordPress post | The editor stripped the script tag | Use a Custom HTML block, not a paragraph block, for the embed snippet |
Alternative Data Sources If Fortnite-API Goes Down
Relying on a single third-party API is a risk for anything meant to run unattended for months. It is worth knowing what else exists before you commit to one source, even if Fortnite-API remains your primary pick for this tutorial because of its free tier and simple JSON responses.
| Source | Cost | Best Used For |
|---|---|---|
| Fortnite-API.com | Free, optional key for higher limits | Primary live data fetch in this tutorial |
| Manual fallback constant | Free (your own maintenance time) | Guaranteed uptime when the API is unreachable |
| Epic Games' official status and news pages | Free | Manually verifying a date before updating the fallback constant |
| Community trackers (fan wikis, Discord announcement channels) | Free | Cross-checking a date you are unsure about |
Notice that three of the four rows in that table are free, which is one of the more approachable parts of this project. The only real cost is your own time spent occasionally checking that the fallback constant still matches reality, a task that takes under a minute once you know where to look. If you are building this for a high-traffic site, it is still worth budgeting for a paid, higher-limit API key eventually, since free tiers on community APIs can rate-limit aggressively during the exact traffic spikes that happen right around a real season transition, which is when your visitors care about the countdown the most.
Whichever data source mix you choose, resist the temptation to add a fifth or sixth fallback layer just because you can. Every extra source is another thing that can silently break, another code path to test, and another opportunity for the widget to show conflicting information if two sources disagree. Two reliable layers, a live fetch and a manually maintained constant, cover the vast majority of real-world outages without turning a small embeddable widget into a project that needs its own on-call rotation.
Advanced Tips: Notifications and Multi-Game Support
Once the base widget works, a few extensions add real value without much extra code. First, wire a browser Notification API call that fires when the countdown crosses zero, so visitors who leave the tab open get pinged the moment a rollover is detected, instead of having to keep refreshing. Second, expose a data-game attribute on the custom element so the same component can track other live-service titles with published season calendars, turning a single-purpose widget into a small reusable library. Third, log rollover events to a lightweight analytics endpoint (even a simple Cloudflare Worker writing to KV storage works) so you can see exactly how long the gap was between the old season ending and the new one actually going live, which is useful data for tuning your fallback constant over time.
If you want the widget to double as a lightweight status page, add a secondary state that reads server status separately from season data, since a season can technically "end" while servers are still up for one final match queue drain. Separating those two signals avoids a confusing UI where the countdown says zero but players report they are still in a live match.
A fourth extension worth considering is a "confidence" indicator next to the countdown, a small label that reads "official" when the target date comes straight from a live API response, versus "estimated" when the widget has fallen back to the hardcoded constant. This is a small UI touch, but it sets accurate expectations for visitors instead of implying a level of certainty the data does not actually support, especially during the stretch of days right before Epic makes an official announcement.
You can also add a simple event bus so other scripts on the page can react to a rollover without polling the widget's internal state themselves. Dispatching a custom DOM event like season-rollover from inside tick() whenever rolloverTriggered flips to true lets any other component on the page, a banner, a toast notification, an analytics hook, listen in with a single addEventListener call, keeping the widget decoupled from whatever else the host page wants to do with that information.
Complete Working Project Structure
Putting every step together, your finished repository should look like this before deployment.
fortnite-season-countdown/
├── package.json
├── src/
│ ├── index.html
│ ├── styles.css
│ └── countdown-widget.js (fetch, cache, Custom Element, all combined)
└── README.mdEverything from Steps 2 through 9 lives inside countdown-widget.js as a single self-contained module. That is intentional: a widget meant to be embedded on third-party sites should ship as one file with zero external dependencies beyond the browser itself, keeping load time low and avoiding version conflicts with whatever the host page already has installed.
A short README goes a long way if you plan to share the project or hand it off to someone else on your team. At minimum, document the embed snippet, the meaning of the FALLBACK_SEASON_END constant, and the cache TTL, since those are the three values someone will need to touch again after the next season is confirmed. If more than one person maintains the site, add a short note on who is responsible for updating the fallback date and how they will find out a new season has been confirmed, whether that is checking Epic's own channels, a fan wiki, or a Discord announcement feed. A widget with accurate code but a stale, unowned fallback date is only marginally better than no widget at all.
Final Testing Checklist Before You Ship
Run through this list once before pointing real traffic at the widget. It takes about ten minutes and catches the large majority of issues that would otherwise surface as bug reports after launch.
- Load the page with dev tools' network tab set to "offline" and confirm the fallback date renders instead of a blank widget.
- Manually set your system clock past the fallback date and confirm the "checking for update" state appears instead of negative numbers.
- Resize the browser to a 320px-wide viewport and confirm none of the four countdown boxes wrap or overflow.
- Switch your OS or browser language setting and confirm the localized date string updates accordingly.
- Embed the widget on a second, unrelated test page with its own CSS framework and confirm no style bleeds through in either direction.
- Leave the tab open and backgrounded for at least ten minutes, then bring it back to the foreground and confirm the countdown has not drifted.
Frequently Asked Questions
When is the next Fortnite season actually launching?
Epic has not published an official date for Chapter 7 Season 5 as of September 29, 2026. The current season, Override, has a reported end date of November 1, 2026, so the next season is expected to follow shortly after, pending Epic's official confirmation. Treat any date you see beyond that as a community estimate until Epic's own channels confirm it, which is exactly the distinction the widget's fallback-versus-live states are designed to communicate.
Is Fortnite-API.com an official Epic Games service?
No. It is a community-maintained project that mirrors publicly available game data. Treat it as a convenience layer, not a guaranteed source of truth, and always keep a manual fallback date as this tutorial does.
Why use a Custom Element instead of a simple div and script tag?
Shadow DOM encapsulation means your widget's styles and internal DOM structure cannot be accidentally broken by the host page's CSS, and vice versa. That makes it far safer to distribute as an embed for third-party sites, since you have no control over what other stylesheets or scripts are already loaded on a page you do not own.
Does this widget work inside WordPress?
Yes, through a Custom HTML block. The default paragraph or text block will strip out script tags, so make sure you paste the embed snippet into a block specifically meant for raw HTML.
How often should the widget refetch season data?
A 15-minute cache window is a reasonable default for most sites. High-traffic embeds should raise that to an hour, since the countdown math itself needs no network call to keep ticking accurately between refreshes.
What happens if the countdown hits zero and nothing changes?
The widget enters a "checking for update" state and keeps polling on the cache interval until the API reports a new season end date further in the future. This is expected behavior during Epic's typical multi-hour maintenance windows.
Can I track FNCS and other competitive dates with the same approach?
Yes. The same fetch-cache-fallback pattern works for any published schedule, including FNCS Solos qualifiers and finals, as long as you point the fetch function at a data source that publishes those dates. You would typically run a second instance of the custom element with a different data-game or data-event attribute pointing at a separate fallback constant for the tournament date.
Is it safe to hardcode a fallback date in production?
Yes, as long as you treat it as a manually maintained value you update when Epic confirms new information, not as a permanent guess. The fallback exists to prevent a blank UI during API outages, not to replace live data entirely.
