Log level 'error' should mean that something needs to be fixed • Hacker News Board

Re: Log level 'error' should mean that something needs to be fixed

#51

Post by bqmjjx0kac » Sat, Dec 20, 2025, 5:41 PM UTC

mewpmewp2 wrote: post #48

eterm wrote: post #45

How I'd personally like to treat them: - Critical / Fatal: Unrecoverable without human intervention, someone needs to get out of bed, now. - Error : Recoverable without human intervention, but not without data / state loss. Must be fixed asap. An assumption didn't hold. - Warning: Recoverable without intervention. Must have an issue created and prioritised. ( If business as usual, this could be downgrading to INFO. )…

What if you are integrated to a third party app and it gives you 5xx once? What do you log it as, and let's say after a retry it is fine.

I would log a warning when an attempt fails, and an error when the final attempt fails.

Re: Log level 'error' should mean that something needs to be fixed

#52

Post by AndroTux » Sat, Dec 20, 2025, 5:43 PM UTC

“cannot contact port 25 on ” may very well be a configuration error. How should the program know?

Re: Log level 'error' should mean that something needs to be fixed

#53

Post by [deleted] » Sat, Dec 20, 2025, 5:46 PM UTC

raldi wrote: post #15

jonathrg wrote: post #14

Earlier quoted context omitted.

Oh that makes sense.

There are still some special cases, because 404 is used for both “There’s no endpoint with that name” and “There’s no record with the ID you tried to look up.”

[deleted]

Re: Log level 'error' should mean that something needs to be fixed

#54

Post by mewpmewp2 » Sat, Dec 20, 2025, 5:46 PM UTC

raldi wrote: post #7

jonathrg wrote: post #6

Earlier quoted context omitted.

4xx is for invalid requests. You wouldn't log a 404 as an error

I’m talking about codes you receive from services you call out to.

What if user sends some sort of auth token or other type of data that you yourself can't validate and third party gives you 4xx for it? You won't know ahead of time whether that token or data is valid, only after making a request to the third party.

Re: Log level 'error' should mean that something needs to be fixed

#55

Post by sysguest » Sat, Dec 20, 2025, 5:47 PM UTC

eterm wrote: post #45

How I'd personally like to treat them: - Critical / Fatal: Unrecoverable without human intervention, someone needs to get out of bed, now. - Error : Recoverable without human intervention, but not without data / state loss. Must be fixed asap. An assumption didn't hold. - Warning: Recoverable without intervention. Must have an issue created and prioritised. ( If business as usual, this could be downgrading to INFO. )…

hmm maybe we need extra representation?

eg: 2.0 for "trace" / 1.0 for "debug" / 0.0 for "info" / -1.0 for "warn" / -2.0 for "error that can be handled"

Re: Log level 'error' should mean that something needs to be fixed

#56

Post by colechristensen » Sat, Dec 20, 2025, 5:49 PM UTC

DanHulton wrote: post #50

colechristensen wrote: post #43

Earlier quoted context omitted.

How about this: - An error is an event that someone should act on. Not necessarily you. But if it's not an event that ever needs the attention of a person then the severity is less than an error. Examples: Invalid credentials. HTTP 404 - Not Found, HTTP 403 Forbidden, (all of the HTTP 400s, by definition) It's not my problem as a site owner if one of my users entered the wrong URL or typed their password wrong, but i…

If you're logging and reporting on ERRORs for 400s, then your error triage log is going to be full of things like a user entering a password with insufficient complexity or trying to sign up with an email address that already exists in your system. Some of these things can be ameliorated with well-behaved UI code, but a lot cannot, and if your primary product is the API, then you're just going to have scads of ERRORs…

You have HTTP logs tracked, you don't need to report them twice, once in the HTTP log and once on the backend. You're just effectively raising the error to the HTTP server and its logs are where the errors live. You don't alert on single HTTP 4xx errors because nobody does, you only raise on anomalous numbers of HTTP 4xx errors. You do alert on HTTP 5xx errors because as "Internal" http errors those are on you always.

In other words, of course you don't alert on errors which are likely somebody else's problem. You put them in the log stream where that makes sense and can be treated accordingly.

Re: Log level 'error' should mean that something needs to be fixed

#57

Post by HankB99 » Sat, Dec 20, 2025, 5:51 PM UTC

AndroTux wrote: post #52

“cannot contact port 25 on ” may very well be a configuration error. How should the program know?

Would it make sense to consider anything that prevents a process from completing it's intended function an error? It seems like this message would fall into that category and, as you pointed out, could result from a local fault as well.

Re: Log level 'error' should mean that something needs to be fixed

#58

Post by kijin » Sat, Dec 20, 2025, 5:53 PM UTC

AndroTux wrote: post #52

“cannot contact port 25 on ” may very well be a configuration error. How should the program know?

SMTP clients are designed to try again with exponential backoff. If the final attempt fails and your email gets bounced, now that's an error. Until then, it's just a delay, business as usual.

Re: Log level 'error' should mean that something needs to be fixed

#59

Post by eterm » Sat, Dec 20, 2025, 5:54 PM UTC

mewpmewp2 wrote: post #48

eterm wrote: post #45

How I'd personally like to treat them: - Critical / Fatal: Unrecoverable without human intervention, someone needs to get out of bed, now. - Error : Recoverable without human intervention, but not without data / state loss. Must be fixed asap. An assumption didn't hold. - Warning: Recoverable without intervention. Must have an issue created and prioritised. ( If business as usual, this could be downgrading to INFO. )…

What if you are integrated to a third party app and it gives you 5xx once? What do you log it as, and let's say after a retry it is fine.

This might be controversial, but I'd say if it's fine after a retry, then it doesn't need a warning.

Because what I'd want to know is how often does it fail, which is a metric not a log.

So expose as a metric not a log.

If feeding logs into datadog or similar is the only way you're collecting metrics, then you aren't treating your observablity with the respect it deserves. Put in real counters so you're not just reacting to what catches your eye in the logs.

If the third party being down has a knock-on effect to your own system functionality / uptime, then it needs to be a warning or error, but you should also put in the backlog a ticket to de-couple your uptime from that third-party, be it retries, queues, or other mitigations ( alternate providers? ).

By implementing a retry you planned for that third party to be down, so it's just business as usual if it suceeds on retry.

Re: Log level 'error' should mean that something needs to be fixed

#60

Post by [deleted] » Sat, Dec 20, 2025, 5:56 PM UTC

mewpmewp2 wrote: post #48

eterm wrote: post #45

How I'd personally like to treat them: - Critical / Fatal: Unrecoverable without human intervention, someone needs to get out of bed, now. - Error : Recoverable without human intervention, but not without data / state loss. Must be fixed asap. An assumption didn't hold. - Warning: Recoverable without intervention. Must have an issue created and prioritised. ( If business as usual, this could be downgrading to INFO. )…

What if you are integrated to a third party app and it gives you 5xx once? What do you log it as, and let's say after a retry it is fine.

[deleted]