Checking the status of a website by hitting a PHP script

I currently have a system which loops through a bunch of my website domains and checks their status and sends me a notification letting me know if they are up or down. The stripped down version of the relay code is below, I've removed the email/DB update code etc.

It pings a transponder (a file on the client website server) which returns 'SUCCESS' or whatever the error it has encountered and returns that as a string.

function checkStatus($domain){
  $statusArray = array();

  $url = $domain . '/transponder.php';

  $statusArray['transponder_response'] = file_get_contents($url);

  if($statusArray['transponder_response'] == 'SUCCESS'){
    //all is well
  }else{
    //all is not well
    $statusArray['transponder_code'] = get_headers($url, 1);
    //send code and response via email to admin
  }

  return $statusArray;
}

The transponder code is such:

$dbInfo['host'] = '';
$dbInfo['dbname'] = '';
$dbInfo['user'] = '';
$dbInfo['pass'] = '';

$link = mysqli_connect($dbInfo['host'], $dbInfo['user'], $dbInfo['pass'], $dbInfo['dbname']);

if(mysqli_connect_errno()){
  printf('Connect failed: %s\n', mysqli_connect_error());
  exit();
}

if($result = mysqli_query($link, 'SELECT 1')){
  if(mysqli_num_rows($result)) echo 'SUCCESS';
  mysqli_free_result($result);
}

mysqli_close($link);

A 'SUCCESS' response means that the site domain is resolving, PHP is working and DB is working.

Can anyone point me in a direction to make this more accurate and effective for site monitoring?

When you say checkStatus($domain), the parameter should either be actually just a domain (without protocol identifier), or you should just specify the full URI. When in doubt, you shouldn't hardcode /transponder.php.

As for the task of status monitoring - testing the database connectivity is certainly not wrong, but keep in mind that far more can go wrong. If you really want to check if the site is working, don't test against a minimal test script, but a real page of that site. Preferably one which does involve as many systems as possible, and check if the output is the expected.

Why? As I said before, there are more possible errors than just the database connection. Commonly you can also run into problem with the session storage, failing server side caches (APC, memcached and alike), resource shortages (e.g. PHP going OOM), and various more.

You should probably also record response times, not only response status. If your server fails to respond timely, it's a warning sign that you should react to immediately before there is a complete outage.

Last, but not least, don't just test a single status page. If you have access to it, rather check the error logs if there were any events in the past interval. Especially during load spikes, not necessarily every request is going to fail. But an accumulation of failures can be easily read from the logs, and should be dealt with. Make sure your application does log warnings and errors properly.

StackExchange Code Review Q#132598, answer score: 2