[Looking for Charlie's main web site?]

Need to know how long your ColdFusionMX instance has been up?

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
If you've ever needed to know how long your CFMX instance has been running, did you know there's an incredibly simple solution? It's not really obvious, and in fact it may not work on trial editions of ColdFusion (for reasons explained below), but it's worked on the Enterprise and Developer editions that I and others have tested it.

Some may have noticed that there is a server.coldfusion.expiration variable (one of many read-only variables in the server scope, within the coldfusion structure). According to the docs, it's supposed to represent the date on which a trial edition of CFMX will expire.

But some have found (and I've confirmed) that on non-trial editions it instead reports the time that the server started. Try it youself:

<cfoutput>#server.coldfusion.expiration#</cfoutput>

It'll be a date, but is it in the future? or the past? Assuming it's the past, and you're not running on a trial edition, then it's likely the time your server had started. If you could restart your server and test again, you'll know for sure. :-)

Better formatting of the result

Now, if you want to easily determine how long the server has been up, just use the datediff function to report how many minutes there are between the time reported and the current time:

<cfoutput>#datediff("n",server.coldfusion.expiration,now())#</cfoutput>
Now, that number will be in the thousands after only one day. If you just want to better format the number of minutes, you could use the numberformat function which (without any formatstring) simply adds commas where they would be appropriate:

<cfset uptime = datediff("n",server.coldfusion.expiration,now())>
<cfoutput>#numberformat(uptime)#</cfoutput>

But even better, you could use one of the nifty functions available at the cflib.org that could help present the result minutes in terms of days, hours, and minutes (duration()). Assuming you included the latter in your page, you could then output the value as:

<!--- assuming you have included or pasted the duration UDF --->

<cfset uptime = duration(server.coldfusion.expiration,now())><br>
<cfoutput>#uptime.days# Day(s) #uptime.hours# Hour(s) #uptime.minutes# Minute(s)
<br>Server started on #dateformat(server.coldfusion.expiration)# at #timeformat(server.coldfusion.expiration)#
</cfoutput>

I may put together a UDF to submit to the cflib to pull all this together, and which also checks if indeed the server being checked is a trial edition, etc. But I'll look forward to hearing people's feedback first.

Other options

Of course, it's worth pointing out that there are of course many tools that will monitor a server's uptime by watching it externally. It may also be possible to ask the operating system to report how long a given process or service has been running. I'll leave that for others to investigate.

Finally, I'll point out that there is indeed a tag in the Adobe Developers Exchange, CF_UpTimeMonger, that purports to help detect server uptime and says it works even for CF 4 and CF5. I have not explored it.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
Nice one. Had been bugging me for a couple of hours, trying to get Windows Server to report the uptime.

For the benefit of other people thinking of trying this out (of which, I'd imagine there are a fair few):
The duration function isn't m,entioned, so I've coded my own.

function duration(past,present){
this.days=dateDiff("d",past,present);

thenDate=dateAdd("d",this.days,past);
this.hours=dateDiff("h",thenDate,present);

thenDate=dateAdd("h",this.hours,thenDate);
this.minutes=dateDiff("n",thenDate,present);

thenDate=dateAdd("n",this.minutes,thenDate);
this.seconds=dateDiff("s",thenDate,present);

return this;
}

Simple enough.. Not sure it needs any explanaton.
# Posted By Chris | 3/12/07 12:40 AM
Chris, glad it helped you. As for the duration function, you say "it isn't mentioned". Do you mean that you wondered why I hadn't offered the code in the blog entry? Perhaps you missed it but I offered a link to the CFLIB directory version of the function and figured people would go there for it. Maybe you just missed that, which is certainly ok. :-) Or perhaps you read the entry in some form where it showed only text and not hyperlinks. Just wanted to clarify.
I had indeed missed the link, it is visible having looked for it now, but you're spot on with reading the entry in some form where it didn't show up, that form was "sleep deprived scanning" ;)

Having clicked the link to it, I noticed that it does a common public domain script thing:
It over complicates the matter in order to make itself seem more complex.

Your examples here suffered from no such thing, don't feel that I'm in any way knocking you. In truth, I thank you for being another rare person determined not to overcomplicate things just to make them seem more complex.

I hate the whole "why use the one line that does the job, instead of using 30 lines to accomplish it, and look cooler" thing - something I've just found myself guilty of in typing this.. So I'll stop now then..
# Posted By Chris | 3/12/07 10:03 AM
No worries, Chris. As for the cflib version, I really didn't study it closely, but I'm glad the author added it, since it was a solution when I needed it for this blog entry. :-)

The author's email is offered in the source code as well, so perhaps he might appreciate your observation of a more compact solution and would update it.

Or, note that they (Ray and Rob, who run cflib) always welcome new UDFs there, so you may want to send yours along as an alternative. There are a few variants on a single theme. :-)

And as for typing too many lines in a comment (or blog, or article, or email), you won't hear a complaint from me. I'm one of the most notorious felons on that charge! :-) i just trust that some will appreciate the additional info. To the rest, I lament that they may miss out on little gems here and there as they learn. To each their own, of course. Cheers.
The comment length police are responsible for a lot of information not passed on, as such, I never complain about a long post, if it's worth mentioning, I'll mention it, in that respect, I can do nothing other than wholeheartedly agree with you.

As for submitting "my" version (which I can't claim ownership to really, the foundation of the language, utilities and such weren't mine, they were a hybrid between Allaire, and MM's collective, and much valued input) not much point, those who look at the duration function as listed under CFLIB will more than likely realise that it can be shortened, and do something similar, if not shorter/better/cleaner than my function themselves.

Since my function teaches nothing, I don't feel it worthy of being a public resource.
Indeed, to further extent, I'm very much against the whole "library" thing anyway, I can't stand copy & paste coding,whatever justification may be applied to it, it's still not the developer creatng a solution that fits perfectly the requirements, often something is pasted in which has additional functionality never used
- "Scratch" is a wonderful material, anything can be made from it, when combined with "understandng"

Besides which, I'm one of those people that give something like that 10 second bit of coding without wanting my name attributed to it, hence no website listed, and only my first name.

Please do take this with a hint of alcohol.. There are most likely some major diversions from original points, but I felt compelled to respond to such an agreeable chap as yourself.
# Posted By Chris | 3/12/07 6:45 PM
Great work Charlie - I was looking for an easy way to report the server uptime for TeamworkPM administration.
# Posted By Topper | 9/26/08 1:42 PM
Glad I could help, Peter (Topper). :-)
[See my next comment, that supercedes this.] I'm sad to have to report that this trick (from the cfmx timeframe), for finding out the CF instance uptime using the server.coldfusion.expiration, no longer seems to work. I have noticed on more than one CF9 server that the expiration date seems fixed at a 2009 date (in my case, Oct 31, and the other was a totally unrelated server, though I didn't note the month and day it reported).

Guess the feature was a fluke, but it was nice while it lasted.

There are some other ways to get the info, as listed in the entry and comment at https://www.raymondc...
I have an update on this post (from 12 years ago!), and it's good news, about this undocumented feature of the server.expiration value reporting the time of a last CF restart.

It seems that it IS still working, at least as long as the CF edition is Standard or Enterprise. it does NOT work if it's in the Developer edition mode.

I had reported back in 2013 that it seemed no longer to "work", at least as I and a couple of other folks noted regarding CF9 then. And I pretty much forgot about it.

But had occasion to discuss it with someone recently and it was working for him on CF11! I tested and it was also working for me on CF2016, but then I tested on CF10 and it did NOT work. That seemed odd.

Then I noticed that the CF10 was running in Developer mode (as reported in the CF admin "settings summary" page (and in the cfusion/lib/license.properties file). I put a Standard license key in place (one can put it in the Admin's "system information" page, or in that license.properties file), and I restarted, and now server.expiration DID show the time of the last restart.

Wow, so it's still working, now 16 years later. :-) Odd that it doesn't work in the Developer edition. I suspect the date then holds when the trial edition expired and the developer edition kicked in. (I would be curious what it would hold if one installed CF as the Developer edition from the start. If anyone may try that, let me know.)

It's sad, though, that this is still not documented. The page on the server scope (https://helpx.adobe....) still only mentions its use for tracking the actual expiration of a trial (when in trial mode).

It would also seem helpful for the undocumented behavior to work on Developer edition like it does on Standard or Enterprise.

I'm thinking I may create a new blog post to "reprise" this one. So many people won't look at a blog post that's more than a year or two old, it seems, thinking it "can't still be valid info"!
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting