Cloudbeds Stale Data Error Report

Prepared 07/04/2026 for external sharing with Cloudbeds regarding `StaleCloudbedsDataError` frequency, pattern, and overnight carry-forward behavior.

Total Stale Hits

Observed in the last 30 days

Daytime Staleness

82.8% of all hits

Overnight Carry-Forward

17.2% of all hits

Days With Hits

06/22/2026 through 07/04/2026

Average Stale Age

179.8

Minutes across all 64 hits

Observed Age Range

21-1012

Minutes stale at the time of detection

Executive Summary

Over the last 30 days, the hourly Cloudbeds snapshot workflow logged 64 `StaleCloudbedsDataError` events. Most were fresh daytime staleness, meaning the Cloudbeds dataset refreshed during the same day but then aged past the 20-minute freshness threshold before the next hourly polling cycle.

A smaller but more operationally concerning subset, 11 events, were classified as overnight stale carry-forward. Those cases indicate the Cloudbeds dataset had already gone stale from an overnight or pre-dawn update and remained stale into later morning or daytime runs.

The average stale age at detection was 179.8 minutes, with a minimum observed stale age of 21 minutes and a maximum of 1,012 minutes. The large spread is explained by the overnight carry-forward clusters.

All overnight carry-forward events were concentrated in just two dataset-freeze clusters tied to a 2:08 AM CDT dataset timestamp.

Methodology

Source log reviewed: `logs/hourly-cloudbeds-snapshot.log`.
Trigger counted only when the full runtime error line contained `StaleCloudbedsDataError`.
The workflow enforces a hard freshness limit of 20 minutes.
Each hit was paired to its scheduled run timestamp from the same log.

Classification Rule

Overnight stale carry-forward: the most recent Cloudbeds dataset update occurred on a prior calendar day or before 6:00 AM local time and was still stale when a later scheduled run executed.
Fresh daytime staleness: the dataset refreshed during the same day in normal daytime hours, then exceeded the 20-minute freshness threshold before a later scheduled run.

Staleness Duration Summary

Measure	Value	Comment
Minimum stale age at detection	21 minutes	Closest observed miss above the 20-minute freshness limit.
Maximum stale age at detection	1,012 minutes	Extreme carry-forward event during the 06/28/2026 overnight freeze cluster.
Average stale age, all hits	179.8 minutes	Overall average across all 64 recorded stale hits.
Average stale age, daytime staleness	73.9 minutes	Shows that same-day refreshes were often still substantially behind the 20-minute threshold.
Average stale age, overnight carry-forward	690.0 minutes	Reflects long-duration dataset freeze behavior rather than short refresh delays.

Daily Breakdown

Date	Total Hits	Overnight Carry-Forward	Fresh Daytime Staleness
06/22/2026	3	0	3
06/23/2026	6	0	6
06/24/2026	6	0	6
06/25/2026	6	0	6
06/26/2026	3	0	3
06/27/2026	5	0	5
06/28/2026	9	9	0
06/29/2026	1	0	1
06/30/2026	5	0	5
07/01/2026	10	2	8
07/02/2026	4	0	4
07/03/2026	2	0	2
07/04/2026	4	0	4
Total	64	11	53

Overnight Carry-Forward Incident Clusters

Cluster	Cloudbeds Dataset Timestamp	Impacted Scheduled Runs	Observed Age Range	Hits
Cluster A	06/28/2026 2:08 AM CDT	06/28/2026 11:00 AM CDT through 07:00 PM CDT	532 to 1,012 minutes old	9
Cluster B	07/01/2026 2:08 AM CDT	07/01/2026 07:00 AM CDT and 08:00 AM CDT	291 to 351 minutes old	2

Operationally, these are the highest-signal events because they suggest the underlying dataset stopped refreshing well before the workflow resumed using it later in the day.

Observed Patterns

Daytime staleness is the dominant issue. 53 of 64 hits happened after same-day dataset updates that simply aged beyond the 20-minute guardrail before the next hourly run.
Overnight carry-forward is rarer but more severe. Only 11 hits, but they represent full freeze clusters where the dataset remained stale for multiple consecutive scheduled runs.
The two overnight clusters share the same 2:08 AM CDT update time. That recurring timestamp is likely worth direct investigation by Cloudbeds.
The current retained log shows no stale hits from 06/11/2026 through 06/21/2026. The first stale hit in the retained log appears on 06/22/2026.

Questions to Escalate to Cloudbeds

Why did the dataset appear to stall at exactly 2:08 AM CDT on both 06/28/2026 and 07/01/2026?
Is there a known Data Insights refresh bottleneck, queue delay, or overnight maintenance process tied to those timestamps?
Can Cloudbeds provide the expected refresh SLA for the relevant Data Insights datasets and reports?
Can Cloudbeds expose a more reliable freshness signal or health endpoint so downstream workflows can distinguish between delayed refreshes and platform-level stalls?

Source basis: `/Users/bobeagle/.openclaw/workspace/logs/hourly-cloudbeds-snapshot.log` and the current workflow guardrails in `/Users/bobeagle/.openclaw/workspace/scripts/send_hourly_cloudbeds_snapshot.py`.

Note: This report is intentionally focused on stale-data behavior, not on message-delivery outcomes or downstream business impact.