# Log Error Discard Settings

Application logs act as the backbone for understanding what is happening inside your application. They capture errors, performance anomalies, and security activities in real time, making them essential for diagnosing and resolving issues in production. However, as logs grow in volume and complexity, extracting meaningful insights becomes challenging — critical issues can get buried among informational or repetitive messages.

yCrash simplifies this process through automated log analysis and intelligent issue detection. At the same time, we understand that not every reported finding requires attention. Some may be false positives, some may be non-critical issues specific to your environment, and others may already be scheduled for resolution, where repeated alerts are unnecessary.

To handle these cases, yCrash provides the Discard Settings feature for app log report. This ensures you are alerted only to the issues that matter, reducing noise and helping your team stay focused on real priorities.

# How to suppress specific log messages using discard settings?

  1. Download discard-settings-log.json from this location (opens new window)

  2. Place this discard-settings-log.json file in the yCrash Server's upload directory (opens new window). If you use remote storage, you can store the discard-settings-log.json file in the root directory of the remote storage (AWS S3 (opens new window), Google Cloud Storage (opens new window)). The yCrash application checks if the file exists locally first. If found, it reads from there. Otherwise, it looks for the file in the remote storage.

# How to configure 'discard-settings-log.json'?

We provide two types of configurations to control how error statements are discarded: Global Settings and App Settings.

  • Global Settings allow you to discard a specific error statement across all application logs, wherever that pattern appears.

  • App Settings allow you to discard an error statement only for a specific log, without affecting other logs.

This flexibility ensures you can either apply suppression broadly or tailor it to a particular application or log file, depending on your needs.

Let’s see an example:

Example: Suppose your application log contains the error statement "Failed at stackPatterns at local due to java.lang.NullPointerException". This is a known issue in your application and you plan to fix it later. Therefore, you don't want yCrash to repeatedly alert you about this error. In such cases, you can add this error pattern to the discard-settings-log.json file.

img

Fig: Error statement which we want to discard it

If you want to discard this error across all application logs, specify the pattern under Global Settings. In the matchPattern field, add the error statement that you want yCrash to suppress, as shown below :

{
  "globalSettings": [
    {
      "matchPattern": "Failed at stackPatterns at local due to java.lang.NullPointerException"
    }
  ]
}
1
2
3
4
5
6
7

img

Fig: Problem mentioned in the JSON file has been discarded

If you want to discard this error only for a specific application log, specify the pattern under App Settings. For example, if your application log name is "yc", then set the logName field to "yc" and include the error pattern under matchPattern, as shown below:

{
  "appSettings": [
    {
      "logName": "yc",
      "patterns": [
        {
          "matchPattern": "Failed at stackPatterns at local due to java.lang.NullPointerException"
        }
      ]
    }
   ]
}
1
2
3
4
5
6
7
8
9
10
11
12

You can also use both Global Settings and App Settings together in the same JSON file as shown below.

{
  "globalSettings": [
    {
      "matchPattern": "Failed at stackPatterns at local due to java.lang.NullPointerException"
    }
  ],
  "appSettings": [
    {
      "logName": "yc",
      "patterns": [
        {
          "matchPattern": "Add your first application-specific problem statement here"
        }
      ]
    }
   ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

yCrash provides flexibility in how patterns are matched when discarding log statements. You can choose from different matching options such as REGEX, WHOLE_WORD, CASE_SENSITIVE, and NONE to accurately control how the error statement should be identified and suppressed.

# 1. REGEX (Regular Expression):

If the error statements follow a pattern rather than an exact match, you can use REGEX to discard all variations of that error. This is especially useful when the same error appears with different prefixes or context, as REGEX allows you to match and suppress them together.

Example: If you have log statements with different prefixes or contexts but all of them end with "due to java.lang.NullPointerException", you can use REGEX to match and suppress all such variations. Here, "matchCriteria": "REGEX" is used to match any log message containing the pattern "due to java.lang.NullPointerException", as shown below:

{
  "globalSettings": [
    {
      "matchPattern": "Add your first application-specific problem statement here"
    },
    {
      "matchPattern": " .* due to java.lang.NullPointerException", 
      "matchCriteria": "REGEX"
    }
  ]
}
1
2
3
4
5
6
7
8
9
10
11

# 2. WHOLE_WORD

If you want to suppress the error only when the entire word or phrase matches exactly, use WHOLE_WORD. This ensures that yCrash discards only the precise message, without affecting similar or partial matches.

Example: Suppose your log contains the exact error message "Failed at stackPatterns at local due to java.lang.NullPointerException", and you want to suppress only this exact message, but not similar ones, then use WHOLE_WORD to ensure only the full phrase is matched.

{
  "globalSettings": [
    {
      "matchPattern": "Failed at stackPatterns at local due to java.lang.NullPointerException",
      "matchCriteria": "WHOLE_WORD"
    }
  ]
}
1
2
3
4
5
6
7
8

# 3. CASE_SENSITIVE

If the error message uses a specific letter casing and you want yCrash to match it exactly as written, use CASE_SENSITIVE. This is useful when the same message appears in different cases, but only one version should be suppressed.

Example: Suppose your application logs contain java.lang.NullPointerException and you don't want to suppress the log which contains JAVA.LANG.NULLPOINTEREXCEPTION, then use CASE_SENSITIVE to ensure only the message with exact casing is matched.

{
  "globalSettings": [
    {
      "matchPattern": "java.lang.NullPointerException",
      "matchCriteria": "CASE_SENSITIVE"
    }
  ]
}
1
2
3
4
5
6
7
8

# 4. NONE

If you want to match a pattern as a normal string without using REGEX, whole-word rules, or case sensitivity, choose NONE.

EXAMPLE: Suppose your log contains the error message "Failed at stackPatterns at local due to java.lang.NullPointerException", and If you want to match a pattern as is, then use NONE.

{
  "globalSettings": [
    {
      "matchPattern": "Failed at stackPatterns at local due to java.lang.NullPointerException",
      "matchCriteria": "NONE"
    }
  ]
}
1
2
3
4
5
6
7
8

Note:

If no "matchCriteria" is explicitly set, it defaults to "NONE".

← Discard Settings →