Sanity Checks

Source: Dev.to

Why sanity checks matter

Weird things happen in production. No amount of test coverage, database transactions, or years of experience can guarantee that unexpected issues won’t surface.
Running sanity‑check scripts against your databases can catch these oddities before they become major problems. In my experience, this approach has been reliable for the past two decades.

When to add sanity checks

Any time you introduce business rules that can’t (or aren’t easily) enforced directly by the database, add a basic check that scans for records violating those rules.

Example rule

Rule: When state = 'paid' then paid_at should not be NULL.

-- Find records where the rule is violated
SELECT *
FROM payments
WHERE state = 'paid' AND paid_at IS NULL;

Send the results to your alerting system (e.g., PagerDuty, Slack, email).

Common sanity‑check patterns

• Referential integrity beyond foreign keys
  Object X belongs_to Object Y and both should have the same Owner Z.

• Minimum relationship requirements

  • All users belong to at least one organization.
  • All organizations have at least one user.

• Special‑case constraints

  • Users marked as super admin should only belong to the organization Foo.

Operational tips

• Frequency – Run checks every few minutes (e.g., every 5 min) for critical constraints, or schedule them as a daily batch for less urgent ones.
• Scope – Limit checks to records created or updated in the past 48 hours to reduce noise.
• Exclusions – Ignore archived records if they’re not relevant to current operations.
• Pre‑deployment run – Execute the checks manually before deploying new code to avoid flooding your alerting system with false positives caused by incomplete or buggy sanity‑check logic.

By incorporating these simple queries into your monitoring pipeline, you can catch data anomalies early and keep production systems healthier.