feat: classify logs based on HTTP statusCode

[difagume]

What is this PR about?

This PR improves log classification by detecting and categorizing logs based on the statusCode field when present in the message.

Currently, some HTTP logs are misclassified despite clearly indicating their outcome via statusCode. This change ensures they are categorized more accurately.

The matcher supports both numeric and string representations, for example:

• "statusCode": 200
• "statusCode": "200"

Classification rules:

• 5xx → error
• 4xx → warning
• 2xx → success
• others → info

TypeScript Playground example

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Screenshots

Screenshot showing the current log classification state.

Greptile Summary

This PR adds HTTP status code-based log classification to the getLogType function in the Docker logs viewer. When a log message contains a "statusCode" field (in JSON format), it is now classified by the status code value (5xx → error, 4xx → warning, 2xx → success, others → info) before falling back to keyword-based heuristics.

• Adds a regex matcher for "statusCode" that handles both numeric and string representations (e.g., "statusCode": 200 and "statusCode": "200")
• Correctly prioritizes status code classification over keyword matching, preventing misclassification of HTTP logs that contain ambiguous keywords
• Status code ranges follow standard HTTP conventions
• No existing tests for getLogType — unit tests would help ensure correctness of both old and new classification paths

Confidence Score: 4/5

• This PR is safe to merge — it's a small, additive change to a UI-only log classification utility with no side effects on backend logic.
• The change is minimal (12 lines added), logically correct, and non-breaking. It adds a new classification path that takes priority when a structured statusCode field is present, with proper fallthrough to existing behavior. The only reason for not giving a 5 is the absence of unit tests.
• No files require special attention

_{Last reviewed commit: 939ff81}

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}