Stale Data Alerts: An Issue When a Cache or Sync Job Stops Refreshing

Last verified on Nov 10, 2026.

What a stale-data issue is about

Some failures leave no error behind. A cache keeps serving yesterday's prices. A nightly sync keeps running and keeps exiting cleanly, but the table it feeds stopped changing days ago. Nobody sees an exception, so nobody looks.

Stale data is the Sazabi detection for that case. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and nothing needs configuring first. It watches for caches and sync jobs that stop refreshing and for the logged evidence that a refresh happened.

Example: a price cache that stops refreshing

This is an example, not output from a real project. A service called storefront-cache rebuilds its product price cache every 15 minutes. After a credentials rotation, the rebuild starts failing quietly. Every run logs a line like this:

2026-11-08T09:15:02Z INFO storefront-cache refresh start source=pricing-api
2026-11-08T09:15:03Z WARN storefront-cache refresh skipped reason="upstream 403, keeping previous snapshot"
2026-11-08T09:30:02Z INFO storefront-cache refresh start source=pricing-api
2026-11-08T09:30:03Z WARN storefront-cache refresh skipped reason="upstream 403, keeping previous snapshot"

Each line is a warning, not an error, and the service stays healthy. Customers keep seeing the last good prices. Hours later the sensor's question comes back wrong: no refresh has finished, though refresh attempts keep arriving. Sazabi opens an issue. An example of what it could say:

• Name: Price cache has not refreshed since 06
  UTC
• Description: storefront-cache has logged refresh attempts every 15 minutes but none has completed. Every attempt since 06
  is skipped because the pricing upstream returns 403.
• Severity: high

The investigation attached evidence, which is the skipped-refresh lines and the last completed refresh. The person who opens the issue starts at "upstream rejects our credentials", not at "why are prices wrong".

Where the question comes from

The sensor asks one thing in plain words: has a source that normally refreshes stopped doing so? Each job is judged on its own rhythm, so a nightly job is not flagged for being quiet all day.

Other sensors come from the agent. It reads your logs, spots the jobs and caches that write to them, and writes sensors for those, such as "tell me when the 04

You can also ask support for a specific sensor in plain words, for example "tell me when the partner directory import has not updated in 36 hours".

What shows up in your project

A detection records a signal and starts an agent investigation. If the problem is real, the investigation opens an issue with the name, description, severity, agent analysis and evidence. If it turns out harmless, it closes without an issue, so a delayed batch that caught up on its own does not page anyone.

From there:

• Ask follow-up questions in the issue thread, for example which tables the stalled job feeds.
• Run sazabi issues agent-prompt to hand the fix to a coding agent.
• Resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI.
• Run sazabi signals list --type sensor to see the signals behind it.

If the same cache goes stale again while the issue is open or ignored, the recurrence folds into it. After you resolve it, a new stale period opens a new issue.

How you get told

A new issue sends an Issue triggered notification. Personal channels are in-app, email, Slack DM and SMS. Shared Slack or Microsoft Teams channels receive an issue only when a delivery rule names them, and rules can match severity, component or owning team. A data platform team can take only its own services' issues that way.

What it needs from your logs

Staleness is only visible if refreshes write to your logs, and logs are the only input. Send the sync workers, schedulers and cache builders through any supported source: the integrations list, OpenTelemetry, or a cloud platform such as AWS. If a refresh never logs, there is no evidence for the sensor to question.

What it does not cover

• A table or cache whose refresh job writes nothing to your logs.
• Whether the data is correct. It checks whether a refresh happened, not what it wrote.

For the vendor-neutral method, read the guide to data freshness monitoring. Refresh results are easiest to question when jobs write structured logs. Issues Sazabi detects are metered, so see pricing. A source that stops sending logs altogether is a different detection, covered on the service went quiet page.

If the whole source goes dark instead, that is service went quiet.