What are some ideas or structure I can use when assigning EventID to events that will be saved to the Windows Event Log?

enter image description here

Some options I've considered

  • Sequential (0... int.Max)
  • Multiple of 10, where the "0" is replaced with how noisy the debugLevel is set.
    xxx0 may represent exceptions, critical information, start, stop etc.
  • ...?

What numbering approach gives you the most insight when a user describes the event in an email or phone?

What is the most useful to support staff?

  • 1
    What is the business value of the event id on the log? You need to answer this first. Next, you need to answer what database type you'll use (file vs. db), then you need to answer what do I do when the log is cleared out? – NoChance Jun 16 '12 at 15:46

Fair warning: Coming up with a scheme like this will require governance in order to keep the scheme useful.

I have been on a number of projects that use a similar scheme as what you're describing. It's very helpful for help desk, L2, and L3 when the scheme is enforced. One of the big advantages is HD can quickly tell to pass on certain messages and pass them up the chain because they indicate more severe problems than what they are trained for.

I would recommend breaking down first by area, then by severity.
Leave yourself LOTS of room between major areas as it's a real PITA, if not downright impossible, to move error numbers around after they are set. It's not a technical challenge, but more of a documentation and re-training challenge.

A simple scheme could be this:
- 1,000's belong to "base application messages"
- 2,000's belong to IO
- 3,000's belong to DB comms
- 9,000's belong to ugly abends that require immediate L3 investigation

where each of the blocks is a major area of your application. User Interface / DB hooks / Config mgmt / file IO / etc... are just a few examples of areas that could receive their own block of message numbers.

Within those groups:
0 - 250 are informational
251 - 500 are warning
501 - 750 are error
751 - 999 are debug / trace (assuming you don't have a separate facility for that)

If you can use a letter indicator at the end of the message, then you could skip this severity subgrouping. But not all event storage mechanisms allow for using a non-numeric character.
Another option would be to use the last digit of the message to indicate severity. In other words, error numbers ending in 0,1,2 are Info, ... 8,9 are debug / sky-is-falling.

Obviously, cater the numbers and ranges based upon your needs, the above are just examples.

This is a similar, but different layout than HTTP error codes.
With the primary difference being that it is an application area driving the organization / assigning of error message numbers. HTTP codes don't really have application areas to break things down by.

I'm not a big fan of just using sequential numbers or using skip counting. First off, there is no logical structure to those schemes and merely gives a hint as to when the messages were created. Knowing that 0010 was created as an error message long before message 750 is pretty much meaningless information.
I would put in a vote for logical organization even within the info / warning / error categories, but that can become very difficult or cumbersome to maintain.

  • Great stuff. But I don't think you are talking about the same thing the OP asked about. – Winston Ewert Jun 15 '12 at 18:44
  • 1
    You are discussing something like HTTP status codes. I think the OP is doing something like assigning a number to each HTTP request. You are looking at the assignment of different sets of numbers. You are looking at the numbers assigned to event types. I think the OP is assigning numbers to individual events. You are numbering classes, he is numbering objects. – Winston Ewert Jun 16 '12 at 3:24
  • 1
    I'm sorry, but I still don't think you've gotten my point. If the log records app shuts down twice, do you record the same event number in both records? Or do the two records each get their own numbers? – Winston Ewert Jun 16 '12 at 14:57
  • 1
    @WinstonEwert - "Now I understand the confusion" even better. I believe that in this case eventID is the same as message error number. It is not the number identifying the unique occurrence of the event or record number in Windows Log parlance. But I may be showing a bias here towards Windows eventIDs and the associated event log. Here's an example Win Security IDs In the example you mention, the same event ID would be recorded twice under two separate event log record numbers. – user53019 Jun 16 '12 at 15:57
  • 1
    Now we understand one another. And given recent comments by the OP on one of the other answers, I have to change my mind as to the interpretation of his question. I think your interpretation is correct. – Winston Ewert Jun 16 '12 at 16:11

use a standard sequential ordering for EventID, if you want to differentiate between logging levels use a separate column. Your alternate idea violates first normal form, and would make creating queries filtered by type far more difficult than they need be.

  • This. Trying to encode intelligence into sequence numbers invariably leads down the wrong path. – Blrfl Jun 15 '12 at 14:55
  • @Blrfl: Except for a checksum, you're correct. I've seen enough compound values in databases. – Gilbert Le Blanc Jun 15 '12 at 15:20
  • This logic is for the Windows Event log. I'm not storing in a database, normalization can't apply if you are constrained to one column in the first place ;). To make things clear, I'm not talking about a unique row number here, I'm attaching an identifier that applies to a class of related events. See updated photo with Event ID column – halfbit Jun 16 '12 at 16:03

Event ID, along with the Source, should uniquely identify each event. That means that your support person when told the source / number should know what error has occurred and the steps that need to be taken to fix it.

We use a lookup table in our database that stores Number, Description, Type, Severity. That way support staff can look up a number (say 5000) and know that it means "record locked by another user". Create a number for each known exception and support becomes much easier.

I strongly recommend against using sequential numbers if there is no other meaning assigned to them. That will give your help desk people no extra information.


I think a combination of sequential with a prefix to indicate category & severity could be good. You could have the first 2 (or 3) digits for severity, the next few for category, and then a sequential number. The whole string would indicate what kind of problem it is and also be easy to trace back to the log file. The problem is that in your code, you now have 3 numbers to log instead of one (if you were to only use a sequential number). If you can use alphabetic characters (such as "E", "I", "W") that could also be useful.

If you're logging to a table rather than a file, then the category, severity, etc, should be in columns separate from the ID.


Sequential increment by 10, but don't use the 1s column until you need to. It's a (very) simple safeguard for future granularity and grouping similar events.

For example, we have statuses 100 for "new record", 200 for "in progress", 300 for "submitted", and so on.

Recently, 210, 220, and 230 were added because extra steps were introduced in the editing process. Because we left gaps in the IDs, we were able to insert the them in a logical place - the range 2* all have to do with "in progress" somehow.

But these additions tend to be rare, which is why I suggest using 10s instead of 100s like we did.

Queries for "all in progress states" are then a simple BETWEEN 200 AND 299. (or, 20 and 29 if you use 10s)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.