Overview

Sentry is a software monitoring system that tracks errors, warnings and performance metrics on both the server and client sides for a website in order to provide a centralized experience for managing your site’s stability and performance.

It provides an “inbox” experience that notifies you, allows you to triage the issues, and resolve them as they show up, giving you visibility to stuff you normally wouldn’t see.

Our primary use of Sentry is to monitor client-side issues, which are often difficult to even know they’re happening. Sentry alerts us to errors that users are experiencing during relatively normal use, whether they’re bugs, misconfigurations, or another factor.

📏 Rules

✅ Do…

🚫 Don’t…

When to Use

We should have Sentry on any site that can support it. If there is an SDK that Sentry can be installed with, do so. Priorities official SDKs, followed by unofficial ones, then bare-code Javascript or PHP installations.

Fixing code errors means having access to the code. Platforms where we don’t easily have full control over the code, such as Webflow, aren’t a good fit for Sentry.

Ideal Implementation

If the site is on a platform where Sentry can’t be installed (or some other circumstance leading us to decide not to use it), the site should be marked as Won’t Use in the Sentry column in the Website Database.

We consider Sentry implemented when:

Initial Installation and Setup

If we want Sentry on a site, and don’t have it yet, that’s a problem and an important task. A Project Manager should task a developer to install Sentry to meet our Core Coverage services.

During the initial installation, you’ll be selecting the closest platform SDK that they have available. For many of the PHP-based CMSs that we have, there won’t be an official SDK. For this reason, you’ll generally choose PHP, and then look for an unofficial SDK.

Installation depends on the SDK being used. Consult Sentry’s documentation for guidance.

Project Settings > Inbound Filters