Log filtering


Papertrail can filter incoming log messages that match one or more strings or regular expressions (regex) of your choosing. Here’s how.

Log filtering is included with all Papertrail accounts and filtered messages don’t consume log data transfer. Filters are specific to a destination, which means that different environments, systems, or apps can have their own settings.

Papertrail’s log filter is an additional tool. The sending client or app can still filter logs, like with the remote_syslog2 exclude_patterns option or by changing an app’s log settings. These filters are independent of any Papertrail filter.

Trying to find a log message in Papertrail’s log viewer? This page covers how to drop log messages, not how to search for them. Visit Search syntax instead.

Quick start

  1. Login to Papertrail and click the Settings menu option. On a standalone Papertrail account, look for a left menu tab called Log Destinations. Users accessing Papertrail via an app hosting service should see a section titled Log Filtering on the main Settings page itself.
  2. On the log filtering settings, enter the case-sensitive string that matches messages Papertrail should ignore. More.

Example uses


Here are a few common uses. See Setup for complete docs.

Filtering all occurrences of 3 messages

This will drop all messages containing any of the 3 strings. All matches are case-sensitive.

Filter 3 strings

Filtering one program or log file from one sender

Imagine you have one program generating log messages that you don’t want. Filter all messages from the program mongod on the system db-server-42 using the regex:

^db-server-42 mongod

The ^ indicates that the match must happen from the start of a log message. The sender name (in this example, db-server-42) is the name as shown on the Dashboard.


Regexes automatically match substrings (unless anchors in the regex specify position, as above). That is, these three expressions are identical:


and will all match any string containing cron, with or without any leading or following characters. Including .* before or after a typical filter rule is unnecessary.

Filtering (“disabling”) multiple sender(s)

Imagine you have two sending systems which are temporarily generating an undesirable torrent of log messages that you don’t want. Filter all messages from the senders system-a and system-b:


Or filter only messages from noisy-file.log on these two senders:

^(system-a|system-b) noisy-file.log


Decide what to filter

Visit Events and browse the full log stream with all log messages. Decide which messages you want to filter.

Create filter

Enter a string or construct a regex that matches each of the messages which Papertrail should filter. For example, to filter all log messages containing debug, enter debug as the filter and choose String.

Test regular expression

When constructing a regex to filter messages, we recommend using Rubular with Ruby version 2.0.0 selected for testing. This isn’t exactly the same regex engine that Papertrail uses, but it’s a close approximation.

Paste the filter expression created above, then copy a sample log message of each message type that should be matched. The expression matches against everything shown in the Papertrail viewer except for the timestamp, so include the sender name, program name, a colon, and then the message (as shown in the Your test string: input box below).

For example:


Since this regex matches the log message shown, Papertrail would silently discard the message.

Finally, paste a log message that should not match. If it still matches, refine the regex.

One notable construct present in Rubular that log filtering doesn’t support is negative lookahead: it’s not generally possible to drop logs whose only unifying characteristic is that they don’t contain some content. Try writing an alternative regex, altering the client’s log configuration, or adding identifiable content to the problem messages. (Other lookaround constructs are also not supported.)

The characters .|()[]{}\^$+?* have special meaning when using a regex and need to be escaped by placing a \ before them. To match log messages containing GET a.b.c type=json, use a filter string that escapes each special character:

GET a\.b\.c type=json

Enable filtering

Log filtering is configured from the Settings menu in Papertrail.

Most users will see a Log Destinations menu option in the left hand menu. Users accessing Papertrail via an app hosting service may see a Log Filtering form field on the main Settings page itself.

Paste the regex and click Update.


Filtering multiple messages

A more complex example would match multiple messages or only messages from certain senders or apps. For example, suppose that these two messages serve no operational purpose:

www42 httpd: - "GET / HTTP/1.0" 200 3


util2 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Find the portion of the log that occurs in all such messages. Here we’ll use - "GET / HTTP/1.0" 200 (a successful HTTP request from the Web server itself) and nf_conntrack: automatic helper assignment is deprecated (a warning which could be repeated). The following would filter all successful web requests (any HTTP status 200-299) and the warning:

Filtering multiple messages

Filtering colorized messages

If your logs contain hidden ANSI color codes, these can interfere with filtering. Suppose that your logs colorize the log level (DEBUG, INFO, WARN, ERROR) that occurs immediately after the program name:

colored log lines

and you want to filter out INFO and DEBUG messages from app1. To match an ANSI escape code, use the regex (\e\[[0-9;]*m)?. For example, to filter the log lines above, use an expression such as:

app1: (\e\[[0-9;]*m)?(INFO|DEBUG)(\e\[[0-9;]*m)?

The regex

/app1: (INFO|DEBUG)/

would not match, even though it appears to align with the displayed character string.

Papertrail’s standard system and program colors are not applied using ANSI color codes, so don’t require any special filtering.

Filtering by sender

Papertrail matches your regular expression against the complete log message as it is formatted in the viewer. This allows you to include the name of the sender and/or program (or a substring of them) as part of the filter.

Using the examples above, to filter each message from only the system shown in the example, use a filter like:

Filtering multiple messages by sender

The ^ indicates that the match must be at the very start of the log. The sender name is the same display name shown on the Papertrail dashboard.

Note: if you use the sender name in a filter and then edit the sender name, the filter will need to be updated as well.

Filter by default

Papertrail’s default policy is to process messages it receives, which means that the filter string is deciding which messages are ignored. While there’s currently no support for an inverse filter (default behavior of ignoring log messages), these two workarounds often accomplish the same behavior:

If you have a filtering requirement that Papertrail can’t serve well, please tell us.