WHMCS status monitoring URL, how to create one that is not part of an existing Virtual host

Hi Guys,

I have this problem, probably more so due to my lack of experience with Apache or whatever underlying system serves webmin/virtualmin

What I would like to achieve is the ability to monitor our servers without having to place the WHMCS status directory into an existing virtual host.

My ideal solution would be a way to place it into a webmin subfolder that can then be served for example




but using the underlying host name.

I don't think that this should be a terribly difficult problem to solve, but I can't find any info on it.

Any help appreciated.

Closed (fixed)


Howdy -- thanks for contacting us!

I'm not too familiar with the WHMCS status functionality, though I'm not sure that you could put that within Webmin/Virtualmin... Webmin has it's own web server, and isn't designed to serve non-Webmin content.

However, if you want to use it in an Apache-based website, you could always create a Virtual Server with your desired name, perhaps disable all features you don't need (for example, you may not need any of the mail related features, which are only necessary when you're going to receive mail for that domain) -- and then create a "status" directory for the content you want.

Hi andreychek,

Thanks for the response, the way you have suggested that I setup the monitoring is pretty much the way we have been doing it.

However this comes with 2 downsides

1) If you create a virtual server then you waste a domain license for nothing.

2) if you slip the status directory into another virtual host, say one that a client is using, its is not very ethical and you also don't know when that user will leave your environment.

This leads me to ask my next question.

Would it be possible to ask Jamie or Joe to perhaps add it as a feature to Webmin or Virtualmin so that the base host server could indeed serve up this one file just for WHMCS?

Sorry, that's unfortunately a lot of complication just to avoid adding a new domain to the server :-)

I'd suggest not looking at it as wasting a domain, I'd look at it as getting to use a domain for status monitoring.

One way to look at it is that you're paying $90/year for your license, which comes out to $7.50/month. Divide that by the 50 domains you get, you're paying 15 cents a domain. So it would cost 15 cents a month to be able to use that domain for status monitoring.

A lot of folks add a Virtual Server to their system that acts as the default domain, and is a main/company domain, often having some sort of company website there. It's one of our suggested ways of providing RoundCube and phpMyAdmin to customers -- putting those in a sub-directory of that central company domain.

Then, you can direct your customers to that central RoundCube and phpMyAdmin installation... that ends up being a lot simpler than having individual RoundCube and phpMyAdmin instalations for each domain on the server.

You could then add your WHMCS status folder to that central domain.

The above would be our recommendation.

If you really just don't want to do that, you could always manually add a new VirtualHost to Apache, and manually configure it to serve content from your desired location... and then upload your status script to the DocumentRoot you setup for that VirtualHost.

That's not something we can offer setup support for, but it'd certainly work if you preferred to go that route.

Closed (fixed)

Thank you for your advice, I will investigate setting up a virtual host in Apache manually.

Status: Fixed ยป Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Just my 2 cents: Going outside of Virtualmin seems penny wise but pound foolish. Personally, I'd recommend spending the 15 cents per month to keep things consistent without need of manual documentation. Especially for critical infra like a billing system. Which is precisely what WHMCS is.

I understand this is only status info but nevertheless, when there is a hiccup it could cause a scramble. WHMCS changes their scripts from time-to-time and a lot of their customers use 3rd party add-ons which change as well.

With a moment of thoughtful naming, it will be easy to find your virtual server years later, remediate the problem, and then get on with your day.