Skip to content

Platform Defaults Troubleshooting

Diagnostic paths for common issues with Platform Defaults. Each entry lists the symptom, the underlying cause, and how to resolve it.

A saved Effort change did not apply to my next operation

Symptom: You updated the global Effort default and expected the next profile operation to pick it up, but it still ran at the previous level.

Causes and fixes:

  • The operation was submitted with an explicit Effort value. Explicit per-operation values win over both the datastore default and the Platform Default. Re-submit without the override, or fix the automation that sets the value.
  • The datastore-level default is set to a different value. Per-datastore values win over Platform Defaults. Update the datastore-level default on the datastore overview page or accept the datastore-level override.
  • The operation was submitted before you saved the new default. Platform Defaults resolve at submission time, so operations already in flight keep the value that was in effect when they started.

AI checks are not being generated after I enabled the automation control

Symptom: You turned on Create AI volumetric checks (or the freshness equivalent) and saved, but no AI check has appeared on your containers.

Causes and fixes:

  • No scan has run since the save. AI check generation happens at scan time on tracked containers. Trigger a scan on a datastore that inherits the new default.
  • The default was inherited only by new containers, not existing ones. Enable Apply to existing datastores and containers at save time to propagate to current containers.
  • The container has a per-container override that keeps AI check generation off. Container-level values win over the Platform Default. Update the container settings or use propagation to overwrite.

An API update reports a lower value than I submitted

Symptom: You called PATCH /api/settings/global-defaults with high_count_rollup_threshold=5000, and the response body shows the value stored as 1000.

Cause: The controlplane silently caps high_count_rollup_threshold at 1000. This limit is enforced server-side without a validation error.

Fix: Submit a value in the range 1 to 1000. If your workflow needs rollup at higher thresholds, coordinate with your data quality team on why the current cap is not enough.

Apply-to-existing did not touch a specific datastore

Symptom: You enabled Apply to existing datastores and saved, but a datastore that used to hold custom values still shows its old configuration.

Causes and fixes:

  • The datastore is soft-deleted. Propagation targets non-deleted datastores (and, for Observability, non-deleted containers). Restore the datastore if you want it to receive the new defaults.
  • The datastore was created after the save. New datastores inherit the default at creation, so the stored value is already the new default even though the propagation summary did not count it.

The Save button stays disabled after I made changes

Symptom: You edited the form values, but the Save button remains greyed out.

Causes and fixes:

  • The values you entered match the stored values (for example, you toggled a switch off then back on). Make a real change to enable Save.
  • You want to propagate the current defaults without changing values. Turn on Apply to existing datastores to enable a propagate-only save.

Reset changes disappeared when I switched tabs

Symptom: You clicked the Reset icon, the form loaded the shipped values, then you switched to another tab and the reset was gone.

Cause: The Reset button loads Qualytics' shipped values into the form without persisting them. Switching tabs discards unsaved edits.

Fix: Click the Save button before switching tabs. See the Reset Defaults how-to for the full flow.