Weather Data for an App: Handle Stale or Missing Forecasts
When a forecast feed fails, an app needs more than a retry. Define freshness limits, outage states and fallbacks so users can judge what information is still reliable.
Storm coverage in France, including reports referenced by Google Trends FR and articles from CNEWS, L’Indépendant and Le Monde, is a timely reminder that people may consult forecasts when conditions are changing. It does not establish demand for a particular app feature. It does sharpen a durable product question: how should a mobile app behave when its forecast provider is unavailable, or the last successful forecast is no longer current? The answer should be designed before an outage. Teams need explicit freshness limits, understandable status labels and a fallback that does not make old information look current. This guide sets out practical decisions for product and engineering teams.
Define what “fresh enough” means for your product
A successful API response is not automatically a usable forecast. Agree what freshness means for each displayed data type: the time the provider generated the forecast, the time your service retrieved it and, where relevant, the forecast period it describes. These timestamps answer different questions. A cached response retrieved moments ago may still contain an old forecast; conversely, a recent forecast may cover a later period than the user is viewing. Store provider timestamps and retrieval timestamps separately, along with the location and time range to which the data applies.
Set age thresholds according to the consequence of being wrong, not a universal number. A low-stakes planning view may tolerate a longer interval than a workflow where users make immediate operational decisions. Define at least three states: current within the agreed limit, delayed but still displayable, and too old to present as a current forecast. Document who owns the thresholds and how they are reviewed. Avoid a single “last updated” value that hides whether it describes the forecast, your cache or the screen refresh.
- For each data type, record its source timestamp, retrieval time, location and valid period.
- Choose and document thresholds for current, delayed and too-old states.
Make provider failure visible without overstating certainty
Treat provider errors and stale data as distinct conditions. A timeout, rate limit or service error means a new request did not succeed; it does not necessarily mean the previous response is invalid. Keep the last known response only under an explicit age policy, and label it with plain language such as “Forecast last updated at 14:20; updates are delayed.” If it passes the product’s maximum age, stop presenting it as current. Say that forecast information is unavailable and show when the last successful update occurred, if doing so will not mislead.
Design a stable outage state for the whole journey, not just a blank card. Preserve useful context such as the selected location, explain whether automatic updates are affected and offer a retry without implying that repeated taps will fix a provider-side issue. Do not substitute a different location’s forecast or silently retain a reassuring condition as though it were live. If the app includes safety-related information, distinguish the forecast feed from any separately sourced official warning and state when that information was checked. Never invent an alert or imply that a forecast confirms safety.
- Use different copy for request failure, delayed data and expired data.
- Keep any warning source and its update time distinct from forecast status.
Plan fallback behaviour, retries and release tests
Fallback should preserve trust, not merely preserve content. A reasonable policy may display the last known forecast for a limited interval with a prominent timestamp, then replace it with an unavailable state when that interval expires. A second provider is another option, but it requires its own coverage, licensing, data mapping and quality decisions; it is not a free or automatically equivalent substitute. If no defensible fallback exists, an honest unavailable message is preferable to a plausible-looking value with unknown age. Make the policy consistent across screens, widgets and notifications so one surface does not imply freshness another cannot support.
Specify how recovery works: retry with backoff, avoid sending a request on every screen redraw, and replace cached data only after validating the new response and its timestamps. Then test outcomes, not just HTTP success. Include a hypothetical scenario in which a user opens the app during a provider outage: first show a recent cached forecast with its age, then show an unavailable state after the agreed limit, and restore the current label only after a valid update. Test clock changes, location changes, malformed timestamps, prolonged outages and recovery. Monitor failure rate, response age and time to recovery so teams can distinguish a provider issue from an app defect.
- Test both stale-cache expiry and recovery to a validated response.
- Track feed errors and data age, with an owner and escalation path.
A resilient weather experience starts with a product decision: what age of forecast remains useful, for whom, and with what consequences? Translate that answer into separate timestamps, clear freshness states, an explicit outage policy and tests for expiry and recovery. Cached information can be a useful fallback only while users can understand its age and limitations. Where it cannot be trusted, show that plainly. These requirements also help teams scope provider integration, operational monitoring and QA before development estimates become commitments.