My team is discussing how we should indicate, in a logbook, whether a specific action ended with success or not. I started putting it like

timestamp | action name (fail)    | description
timestamp | action name (success) | description

One of the team members suggested replacing fail/success with OK/NOK:

timestamp | first action name (OK)    | description
timestamp | 2nd action name (NOK)     | description

I wouldn't mind such a detail, if he didn't say it would improve readability. I doubt it:

  1. OK and NOK correlate to 66 %, so arguably when quickly going through a lot of text, it is probable to confuse NOK for OK. To the contrary, fail has 0 correlation with success.
  2. fail has a varying letter height, which success doesn't, making them look very different.

Am I thinking in the right direction? Is there any resource where I can read about such details? I believe something like this should be very well known in the area of cockpit or nuclear power plant control room design.

  • 106
    Yeah I don't really know what NOK means
    – UXerUIer
    Commented Jun 7, 2016 at 14:08
  • 12
    Also improving readability how? Honestly to me fail/success improves readability since I'm able to make a very clear distinction between the two.
    – UXerUIer
    Commented Jun 7, 2016 at 14:11
  • 27
    NOK is not a very common, it apparently has 3 more common definitions that I'd argue are also uncommon.
    – DasBeasto
    Commented Jun 7, 2016 at 14:12
  • 88
    I would say this is NOK
    – Midas
    Commented Jun 7, 2016 at 14:34
  • 42
    If success is the normal, common state, why print "success" at all. Just print FAIL whenever a task failed?
    – user31143
    Commented Jun 7, 2016 at 14:59

15 Answers 15


It appears that the biggest problem is being able to find the status indicators within a large group of text.

Barring some significant technical limitation, I would say your solution should be to display the status of each action in its own column.

This makes your question of exact terminology much less important by

  • Reducing the importance of terminology for the sake of visibility
  • Providing a clear, easy to scan column that displays the statuses in a consistent location

But to actually answer your question, I'd go with the "fail/success" pair without considering the exact context in which you're displaying this information.


If the output is binary (success/fail, OK/NOK, whatever), why not only show a status on the failure state?

timestamp | action name           | description
timestamp | action name           | description
timestamp | action name (FAILED)  | description
timestamp | action name           | description


Some comments to the original question have mentioned that the ability to quickly scan and find errors is desired. In that case, I would recommend adding an additional column, but still only displaying failed cases.

For example:

  | timestamp | action name           | description
  | timestamp | action name           | description
! | timestamp | action name (FAILED)  | description
  | timestamp | action name           | description
  • 15
    One minor consideration here is if it's possible (and it usually is, even if you don't think it is) that the task could silently fail, get stuck, never complete, or the status reporting itself could fail, etc. In an ideal world you might have a temporary status like (Working...) or In progress... that is removed on success or failure, so when skimming a list, the "stuck" tasks stand out as much as cases where the task failed but the failure reporting succeeded. Commented Jun 8, 2016 at 8:25
  • 3
    @user568458 often you can't just change what you've previously logged.
    – OrangeDog
    Commented Jun 8, 2016 at 10:29
  • 5
    @OrangeDog yeah, that sort of limitation is why I say "in an ideal world". The important thing is avoiding a situation where if a task gets stuck, or if everything fails including the error logging, the output makes it look like a success. For old-school logging appending to a file, options could maybe include only writing the output on completion (so stuck tasks would be completely absent), or only writing the description on completion (so stuck tasks would be noticeably incomplete) Commented Jun 8, 2016 at 10:41
  • 1
    If you don't mind unicode, you can also use the check mark character (U+2713): action name ✓ for successfull operations (if there is a third state, where an action is still not completed)
    – Falco
    Commented Jun 9, 2016 at 8:49
  • 1
    @Falco I like the idea of marking completed actions, but I would lean more towards only marking actions that fail or don't complete. Assuming that most actions won't fail, a column that's blank for the majority of lines makes it easier to find the problematic lines. Commented Jun 10, 2016 at 18:29

What you need to examine is the use-case for these terms within the context of the project logbook. I have to guess here but I'd say the logbook is a project management tool - an aid to charting progress or discovering problems/blockers

'NOK' is not a commonly understood term. This means that anyone joining your team for reasons of scale, sickness cover, etc, as well as anyone outside your team auditing the project would need to have this term explained to them. Whereas 'success' and 'fail' make perfect sense to anyone capable of reading English.

If you want to improve the visibility of one or other of the two states then I suggest you look for a non-linguistic solution such as placing a shape next to failed items in the list.

  • 1
    Moreover "success" or "failure" are a lot easier to search for. Searching for "OK" with a simple search string will also match all the "NOK".
    – Rolf
    Commented Jun 24, 2019 at 21:07

Two things to think about:

In computing, it's common to use failure instead of just fail, because it happens to be the same number of characters as 'success', so in mono-spaced fonts they end up being the same width. (Side note: "warning" is also the same number of characters) In addition to this, some systems (like Linux/Unix) color the words - failure is usually colored red, and success is usually colored green/blue. So in these systems it's not the [dis]similarity of the words, or the fact they have the same character width that helps identify warnings/errors, it's the color that helps identify failures.

Word coloring is one technique I've seen in the aerospace industry, used with actual avionics equipment in cock pits.

The fact that success, failure, and warning are the same length means that the log message will start at the same location on each line. Eg:

timestamp | action | FAILURE | message/description
timestamp | action | WARNING | message/description
timestamp | action | SUCCESS | message/description

Which can help many people with readability. It's easy to ignore the first 3 columns if they're all the same width. And once you've identified failures/warnings, the most important columns for a human is probably the message/description. Action may be important, but if you see the error message you'll usually have a clue about what to do regardless of what action was taking place. Consider this [slightly contrived] counter-example where each status is a different width:

timestamp | action | fail | message/description
timestamp | action | successful | message/description
timestamp | action | warning | message/description

Now think of seeing that with dozens or hundreds of lines - it gets hard figure out where you need to focus your attention. Of course the simple fix there is to pad the status field with spaces, but then you might lull yourself into discerning status based on word width in the status column (which seems to be your current dilemma).

At least in the aerospace industry, I've seen the use of "GO/NO-GO" for indicating status. NO-GO can also be represented as NOGO or NGO, which is similar to your NOK. I would argue that this is much more widely known, used, and easy to understand for newcomers. And it assuages the concerns many commenters and some answers have pointed out in the more uncommon "NOT OK"/"NOK".

So I would probably do a bit of everything, if possible - take Andrew Martin's answer and use a symbol, color the letters, and pad spaces so the actual messages that you (as a human) want to read are all lined up. Of course this all depends on what kind of UI/format we're talking about - terminal? text file? rich text file? HTML? etc

  • I was going to suggest coloring but even avoiding words altogether if possible. A simple red and green dot would probably be best if there is a brief explanation of what red and green means.
    – Rob
    Commented Jun 7, 2016 at 21:30
  • you can leave the padding out, if you reorder the columns. you can use timestamp | failure | action | message and you won't need any padding because the first three columns start on the same letter number/
    – Armin
    Commented Jun 8, 2016 at 2:31
  • 6
    @Rob don't forget colorblindness. Red and green are good as additional cues, but they must not be the only way to distinguish between things.
    – user31143
    Commented Jun 8, 2016 at 5:30
  • @dan1111 Then black and white or gray. Or is it grey?
    – Rob
    Commented Jun 8, 2016 at 13:12
  • 2
    I think relying on anecdote and personal experience for whether a term is more widely known is very dangerous if you are talking about newcomers to the system. "NGO" and "NG" are just as alien to me as "NOK"; as far as I'm concerned you might as well use "ZQX", because I would read all of them as "this column normally says OK, so I guess this means something went wrong".
    – IMSoP
    Commented Jun 9, 2016 at 11:43

You could use pass/fail. This would satisfy the condition of making the words look different, but has the advantage of being the same number of characters.

timestamp | action name (fail) | description
timestamp | action name (pass) | description

As a further consideration, "OK/NOK" is clearly binary and only allows two possibilities. "Success" and "fail" more clearly allows for further possibilities - "warning" has already been described above as a third state, or "could not run" if preconditions are wrong, or "comms error" if the test was started but you couldn't get data back, or... You get the idea.


At a guess, I think your colleague is talking about readability because of verbosity. i.e. he doesn't want the success / fail to make the description harder to read

So why not have just (!) for failures, and nothing for success

timestamp | first action name       | description
timestamp | 2nd action name (!)     | description

This isn't usable for a first-time user as you'd have to explain that. However this is a log file so I wouldn't expect basic users to be looking at it but hopefully any developer should understand this and remember this as soon as they've been told it once.

At least this might get your colleague off NOK and will save you some bytes along the way.

Edit: I've now just spotted this is somewhat similar to @Andrew Martin's answer


I think the reason is psychological and has nothing to do with readability.

A NOK, not-OK, sounds way less harsh then a FAIL, FAILURE or ERROR. It's just a way to not have to use those "negative" words.

In my opinion you should not budge.

  • Though it was not the question, I appreciate your elaboration on the topic. NOK is a typical term in our environment, so it wasn't the essence of the problem. But I never took care to think why we are using this strange NOK.
    – texnic
    Commented Jun 10, 2016 at 20:57

I know this thread is old, but in case anyone finds this useful: I don't know where you are from, or what field you work in, but in my field (industrial automation), OK/NOK are a de facto standard in Europe. If your colleague used to work/works in automation, maybe it is just what he is used to. However, I would point out that these are mostly shown on color screens and usually accompanied with green/red color. In a plain text log, I would definitely choose another way, unless the customer specified otherwise. Most likely what Harrison Paine suggested - no text for OK result and whatever you want for Not OK result.


Assuming there aren't any limitations on allowed characters, I always find emojis are great for easy readability of success/failure states, as they're the only way to render something in color within plain text alone:

timestamp | first action name | ✅ | description
timestamp | 2nd action name   | ❌ | description

For better accessibility (color-blindness, screen readers, etc.) it'd be better to include a text alternative too:

timestamp | first action name | ✅ success | description
timestamp | 2nd action name   | ❌ fail    | description

When looking at a log file there are two very important things. First finding the problem (or information) quickly, and being able to search for that information.

timestamp STATUS Action Details of the log entry 
timestamp STATUS Action Details of the log entry
timestamp STATUS Action Details of the log entry

Should do that quite nicely. It's important that time-stamp and STATUS are left most. First because it's easier to line up, and second because it's what you care the most about. You start out with a "failure around 6pm". So you scroll to 6pm time stamp and start hunting for a failure.

Next issue is the ability to search log files. No one ever reads /var/log/syslog unless there having a really bad day. Instead they either tail it of grep it. With that in mind you want to have a FAIL and a OK look very different. I prefer -OK- and FAIL. Again this makes line up trivial, but more importantly my eyes can catch the difference between the two if they change rapidly. That is important for tail -f /some/log/file

It also works well with greping cat /some/log/file | grep FAIL will work very well. NOK and OK will not. They will both match "OK".

In short use -OK- and FAIL admins everywhere will appreciate that.

  • for the other statuses in some of the comments and answers you can use WORK and WARN
    – coteyr
    Commented Jun 9, 2016 at 16:06
  • The question was about a logbook, not a log-file. Therefore the width is not an issue. It could be hand-written :)
    – texnic
    Commented Jun 10, 2016 at 20:55

If you're just looking to replace the harshness of "FAIL", I'd suggest GO/NO GO.

In addition to give you a alternative to "success/fail", it gives your meetings a NASA-esque feel to them.


If your output device supports colour, you could colour-code the text in addition to putting a status message next to it. That way, it will be easy to see what was successful and what failed, no matter what actual text is used. You wouldn't have to store the colour information in the log file, but could add it dynamically when the log is displayed (this depends on whether or not your log file is displayed in a text viewer or in a bespoke log viewer).

Remember though that colourblind users may not be able to see red and green clearly, so make sure that there is some way to configure the colours used or offer an alternative black-and-white version (i.e. you still need a status message, not just colours).


YES, it is better than success/fail because success inclines to multiple interpretations.

how would one treat successful cancellation of the operation? is it a fail or success?

i think using pass/fail is more appropriate for boolean states, same as ok/nok.


NOK is definitely confusing. I'd personally go with Ryan's answer (FAILURE/WARNING/SUCCESS), but it's worth to mention another "standard": OK/KO. It's short, they have the same number of characters, it's understandable (KO is clearer than NOK I believe), but it lacks semantics compared to FAILURE/WARNING/SUCCESS.

Update: It seems OK/KO is specific to France, I didn't know that before

  • 20
    Let's try this out: OK OK OK OK OK OK OK OK OK KO OK OK OK OK OK OK OK OK OK OK OK OK KO OK OK OK << Quick! How many failures occurred? Commented Jun 8, 2016 at 10:54
  • 1
    @Substantial: 2
    – Bolu
    Commented Jun 8, 2016 at 12:26
  • 3
    Yeah, except the author prints new lines every time, not a sequence of OK KO, so no
    – Thiht
    Commented Jun 9, 2016 at 11:52
  • 4
    -1. If I just saw "KO" as a status, I would have no idea what that meant. However, if I saw "Success" as a status, I would have no questions at all. Commented Jun 9, 2016 at 15:23
  • 1
    OK/KO is very popular in France but is not understood outside.
    – jlliagre
    Commented Jun 10, 2016 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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