When building software or working with data, things often go wrong in subtle ways. A script crashes halfway. An app behaves strangely. A dashboard shows negative sales numbers. And many times, the root cause is surprisingly basic, such as a file being missing, a variable not being set, or an assumption quietly breaking. That's where sanity checks come in.

Not all bugs come from deep logical errors or broken dependencies. Sometimes, a system breaks because something simple was overlooked.

Sanity checks are like quick mental tests you run in your code to ask, “Does this even make sense?” They're not full test suites or deep validation systems. They're small checks that help you avoid wasting time or accidentally making things worse by continuing with bad data or broken assumptions.

These checks are valuable when working in environments where assumptions can silently fail, such as during deployments, user input handling, third-party API integration, or dynamic configuration. They help you catch what's obviously wrong before your system has a chance to behave unpredictably or fail in confusing ways.

Laravel: Checking Mail Config

Imagine you're working on a Laravel application that sends emails through a transactional email service, such as Postmark or Mailgun. Before queuing up any notifications, ensure your .env file is configured correctly. Without a sanity check, a typo in MAIL_FROM_ADDRESS or a missing API key might lead to failed jobs, broken UIs, or silent bugs.

Here’s an example of a basic sanity check placed near the top of your notification logic:

if (empty(config('mail.from.address'))) {
    throw new RuntimeException('Sanity check failed: MAIL_FROM_ADDRESS is not set.');
}

if (empty(config('services.postmark.token'))) {
    throw new RuntimeException('Sanity check failed: POSTMARK_TOKEN is missing.');
}

It's not about testing whether email sending works. It's about making sure you're not about to try it with missing information. This alone can save you hours of debugging.

JavaScript: Validating Inputs and Env Vars

In JavaScript, similar patterns are common when working with user input or API responses. Suppose you're building a frontend form that allows customers to submit a review:

if (
  typeof form.rating !== 'number' ||
  form.rating < 1 ||
  form.rating > 5
) {
  throw new Error('Sanity check failed: Rating must be a number between 1 and 5.')
}

This check doesn't guarantee the rating is meaningful or submitted by a real user, but it ensures that you're not processing invalid data.

Or in a Node.js server environment, before connecting to a database:

if (!process.env.DATABASE_URL) {
  console.error("Sanity check failed: DATABASE_URL is missing.");
  process.exit(1);
}

This kind of early failure helps avoid more subtle issues later. It's easier to stop with a clear error now than to try debugging broken queries in production.

CI/CD Pipelines: Catching Deployment Mistakes

Continuous integration and deployment pipelines move quickly and often run with minimal human oversight. In these environments, a missing configuration file or an undefined environment variable can cause a deployment to fail silently. Sanity checks provide a last line of defence by validating what must be in place before code is shipped.

Before deploying a Laravel app, for instance, you might run a shell command in your GitHub Actions workflow:

- name: Check .env file
  run: |
    if [ ! -f ".env.production" ]; then
      echo "Sanity check failed: .env.production file is missing."
      exit 1
    fi

Or maybe you want to ensure a critical file, like a compiled CSS or JavaScript bundle, exists before pushing to production:

[ ! -s "public/js/app.js" ] && echo "Sanity check failed: app.js is empty or missing." && exit 1

Local Development: Avoiding Misconfiguration

Sanity checks aren't only valuable for production, but also essential for ensuring quality. In local development, they help prevent confusion when switching environments, onboarding new team members, or starting up complex projects. A simple check can make sure you're not using production credentials in a test script or running the wrong version of a tool.

if (app()->environment('production') && empty(config('app.url'))) {
    throw new RuntimeException('Sanity check failed: APP_URL must be defined in production.');
}

if (process.env.NODE_ENV !== 'development') {
  throw new Error('Sanity check failed: This should only run in development mode.');
}

These small additions save time and confusion when switching between environments or onboarding new developers.

Of course, sanity checks can be overused. If the checks are too vague, such as if (!data) not explaining what data should contain, they provide little help and can even be misleading. A failed check might appear to be a bug in the logic rather than a missing assumption. Always aim to make the cause of failure obvious.

So, the key is to use them wisely. Focus on the things that must be true for your code to work. Place sanity checks early in your logic, before real processing begins. Make them fail loudly and quickly.

They don't make your code perfect. But they do protect it from the most avoidable kinds of failure. They help you catch mistakes at the cheapest possible moment, before you've invested more time or exposed more risk.

Sanity checks do not replace tests. Unit tests confirm that your logic is correct. Sanity checks confirm that your assumptions are even worth testing.

A good sanity check is like switching on the lights before walking into a room. It doesn't fix the room. However, it reveals what's there and what might be wrong. That's often all you need to avoid stepping on something sharp.