Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: phranque
These days, things have changed. I'm responsible for a fairly large distance education environment and one of the things we are now being very proactive in our approach to are errors! When you have 500+ students accessing streams, quizzes (1,000's of questions and answers), there are all sorts of things that creep up.
We've developed a system on our Windows server(s) that now reports "all" errors to the system administrators. This is done via an ASPEmail script and works like a charm. The emails are formatted a specific way to allow recipients to easily filter and address them.
We've set up custom 400 and 500 pages for the visitors that give them friendly error messages along with details of the error if they wish to keep a copy of it. The message tells them that the system administrators have been informed of the error and it will be addressed within 24 hours, that's our normal turnaround time.
If there is one thing I've learned from this entire process, that is the importance of being Proactive vs. Reactive when it comes to dealing with errors. Those 500 errors will kill the visitor experience and getting notified immediately when they occur is something that every web developer should have easy access to.
Is this something you are concerned with? Do you have systems and methods in place to effectively manage site errors? How do you do it?
if an error occurs, i serve up a specific 500/40x page and get the web application to instantly send me an error email, so i can quickly fix the problem.
it's currently a horribly reactive method to sit and wait for problems to happen, but the most thorough testing will not get all issues within the stupidly small timescales us web developers are given. and it's better than somebody emailing in a 500 server error to somebody who then starts to panic. i'd rather it go straight to me who wont panic, and just get it fixed.
Yesterday I set up a 500;100 to catch ASP errors and give the user a soft bump should an error occur. I set up a new page that looked nice for the user but also sent an email and SMS'd me with details of the problem. Let's just say that I was busy last night sorting out some coding issues I would not have been aware of had this new page not been there.
I kind of feel like I'm being both proactive (handing an error situation in a positive, controlled way) and reactive (in the sense that now I can now react quickly to errors and correct them). Well, that's my interpretation anyway.
Does anyone know how I can catch the http status code (and any additional details) in ASP so that I can create one page to handle all the various situations.
It would be good to see a quick list of the sort of problems that had to be fixed, so that others don't make the same mistakes.
The list could be quite long and specific to the application. I've found the process of tracking 400 and 500 errors to be a very "eye-opening" experience and one that I would definitely recommend to all involved with development.
Edward, I ran into an error yesterday while doing this...
No problem, we've already addressed it and you should be good to go.
Proactive is the way to go. They say for every one (01) error reported, there are nine (09) others that are not being reported. That should be enough incentive in itself to look into something like this. ;)
Many times it happened that the notification emails been deleted once the error has been rectified and then suddenly I found some related bug but do not have any supportive data to relate it to the previous error.
Therefore, I think error logging is also crucial part that will allow you to inspect past errors and help you in rectifying future ones.
The script will email you:
Error code and definition
Date and Time
Website the error occurred on
$ip = getenv("HTTP_CLIENT_IP");
$ip = getenv("HTTP_X_FORWARDED_FOR");
$ip = getenv("REMOTE_ADDR");
$ip = "UNKNOWN";
$definition="Internal Server Error";
case 403 :
$subject="$url Error $errorcode";
Error: $errorcode $definition
When designing your notification and/or logging system, keep it simple. You want to minimize the dependencies of the error-handler. For example, if you have a problem with your PHP configuration which causes a serious problem running PHP code under certain circumstances, and you then try to use PHP to report or log that error, then you'll get knock-on errors, with a server error causing another server error, etc.
So error handling --especially that for the 500-Server error-- should be kept as simple as possible.