Thursday, March 19, 2009

4 Ways to Distribute Your Error Reports

Following up on my last post about Error Report Contents I’d like to identify 4 ways an error report can be distributed.

Error reports can be distributed in the following manner;

Mainframe or application logs: Such reports can be deleted when the time limit has been reached. This will take space and has limited search capabilities.

Email alerts: Great for filing up your inbox. If you’re ambitious enough you can sort, organize, follow-up or delete them.

Webpages: Having them on web pages provides that modern look and feel and provides access to anyone you wish. You can then drill down to gather further details on the error, job, and even further details. Can be a bit cumbersome to manage.

Database tables: In this form you can query the results, and maintain a history in an easy to read format, provided you have the right skills.

Recommendation: Regardless of how you look at it. In a support role, you need to action incidents quickly. To do that use email alerts, once completed you can delete them and keep your inbox clean. Furthermore, you want to report on them, so only delete them if you have a record of them elsewhere. The best bet is to have your errors written to a database table where you can create some KPI’s on files or even source systems (another tidbit to keep in mind for error reports). SQL will allow you to create some good KPI's and identify key trouble areas. With those indicators you will be able to take corrective actions on systems and files that just don't measure up to any service level agreements you may have in place.


  1. Daniel

    One other approach that I am starting to use is to make use of an internal blog (my employer under-uses Sharepoint so I'm starting to roll out blog and wiki portals as part of a larger project). I then give people an RSS feed to the blog so they don't even have to remember a URL.

    The status reports will be produced with a little narrative not just as dry reports but as news stories on "How we're doing".

    Thanks to Andrew Brooks for the tip, and the mantra of "making the invisible visible".

    I'm hoping to write up a report on how this experiment works out for the IAIDQ in the future (once things are bedded in).

  2. Daragh that's a great idea, I look forward to seeing that report. RSS feeds are a user friendly way of communicating any type of error report. I imagine we'll see more usage of RSS feeds, and WIKIs as error reporting goes.