Docs / Observability / Config fallbacks

Config fallbacks

Mesedi's Settings page shows an inline orange warning on a config tile when the backend silently fell back to the hardcoded default during the last 24 hours instead of using the value you saved. This page explains what the warning means, when it's safe to ignore, when to escalate, and how to recover.

What it means

Every per-project tunable on the Settings page (time budget, provider-incident minimum tenants, tool return-value byte cap, etc.) is read from our database at the moment the detector runs. If that read fails — a transient connection blip, a brief query timeout, a temporary inability to reach the row — the detector falls back to the hardcoded default so it can still produce a verdict. The fallback is logged as an operational event, which is what produces the warning chip.

The warning is not about your value being wrong. It's telling you that during the warning's time window, your value was not the one in effect.

When to ignore

• The chip shows a small count (1-3 events) and disappears on the next page reload. That's a transient blip — common, harmless, no action needed.
• You just changed the value and refreshed within seconds. Brief inconsistency is expected while the value propagates.

When to escalate

• The count keeps growing across hours and re-saving the value doesn't clear it.
• You see warnings on multiple unrelated config tiles simultaneously. That's a likely sign of a backend health issue, not a per-config problem.
• The count is large (50+) over a 24-hour window. That indicates persistent degradation, not a transient blip.

How to recover

1. Re-save the config value on the same tile. This forces a fresh write and confirms the row is reachable.
2. Reload the Settings page. The chip queries the last 24 hours; events older than that age out automatically.
3. If the chip reappears after a reload, escalate via your tier's support path.

Why operational events are separated from your audit log

Customer-initiated admin actions (creating an API key, revoking a webhook, closing an account) live in your audit log at /app/audit-log. System-initiated operational events — config fallbacks, pricing-table lookup misses, internal retries — live in a dedicated system_events table introduced in migration 050.

That separation keeps the audit log focused on actions you took and need to defend. System events feed the operational chips and rollup banners but don't pollute the compliance trail.

Configurable window

The dashboard chip queries the last 24 hours by default. The underlying API endpoint accepts a ?window_hours= query parameter in the range 1..168 (one hour to seven days) for ops teams who want a shorter or longer view. See the API reference for details.