Add a “Show logs” link to your own internal dashboard, without any API integration. Jump straight from your dashboard to the related logs.
Here’s how to generate a dynamic “Show related logs” link anywhere you have a user ID, string, UUID, timestamp, request ID, email address, or system name that an engineer may want to investigate further.
Imagine you’re sending logs from a Web app to Papertrail, and they include an IP address. Your app’s admin dashboard probably tracks the IP that a user most recently logged in from. Have your admin dashboard dynamically generate a “See user’s history” link (to all request logs containing that IP), or links to see logs from specific sessions or events by timestamp.
Generate a link like this:
Decide whether you want to link to all events, only events from a specific group or log sender, or events matching an existing saved search. To link to all events, link to:
To link to a specific group or system, navigate to events from that group or system in Papertrail. The URL in your browser is the URL to link to. These typically follow the format:
/events is optional but avoids an unnecessary redirect.
To link to multiple systems/senders which do not exist as a group, use
For example, to search for
"Fatal error" within all senders containing
To link to a saved search, use:
To obtain a search’s ID, visit the Dashboard and look at the URL (in the link to this search). The number after the last slash is the ID.
This will redirect through Heroku’s single sign-on. Papertrail will still honor the original URL query parameters. For example:
With a few exceptions, links to systems can use their Papertrail display name (as shown in Papertrail’s dashboard). This makes it easy to generate dynamic links from a monitoring service, without needing to first find the system’s Papertrail ID.
Here’s how name-based URLs let us add a related logs link to New Relic without using Papertrail’s API at all.
After deciding which set of events to link to, optionally add a timestamp in the
time query parameter and/or a search query in the
q query parameter.
Note: Linking to a saved search essentially provides the search query. For that reason, only the
time parameter may be used in links to saved searches; the
q parameter is not relevant.
Here’s an example that searches for
188.8.131.52 (in all logs):
Here’s another example, searching for
error in logs from the system named
bigserver, seeked to
2 hours ago:
time value can be an absolute time in seconds since the epoch (Unix time):
Absolute timestamps should be in UTC.
You can also refer to a saved search instead of providing the search query as a parameter:
See HTTP API to perform search queries directly.