Monitors
A monitor watches your production traffic and opens an incident when a condition you care about is met. Each monitor has one or more alerts, and each alert watches a single signal with its own condition and severity. When any of a monitor’s alerts fires, Latitude records an incident and sends you a notification through your existing notification channels.
Monitors live on the Monitors page of each project. Open it from the project sidebar.
System monitors vs. your monitors
There are two kinds of monitors:
- System monitors are set up automatically for every project. They watch your issues and are marked with a System badge. You can’t create, rename, or delete them, and you can’t change what they watch, but you can mute them.
- Your monitors are the ones you create. Today they watch saved searches. You have full control: add and remove alerts, rename, mute, and delete.
The Monitors list shows both, with columns for:
| Column | What it shows |
|---|
| Monitor | The monitor’s name, plus a System badge for system monitors |
| Status | Live (alerts are active) or Muted (still recording incidents, but not notifying) |
| Last incident | When the monitor most recently fired, or — if it never has |
| Condition | A plain-English summary of the monitor’s first alert, with a +N badge when it has more |
The three system monitors
Every project comes with three monitors that watch the issue lifecycle. Each one notifies you about a different moment:
- Issue discovered: fires each time a brand-new issue is detected in your traffic.
- Issue regressed: fires each time an issue you had resolved is detected again.
- Issue escalating: fires when an ongoing issue is being detected more than expected for this time of day and week. This is the one monitor with a tunable knob: its sensitivity (a value from 1 to 6) controls how large a deviation from the normal pattern is needed before it fires. Open the monitor and edit the alert to change it.
System monitors can’t be deleted: they’re part of how Latitude keeps you informed about issues. If you don’t want to be notified by one, mute it (see Mute below).
The three system monitors replace the old per-project issue-notification checkboxes. Tuning who gets notified, and on which channel, still happens in your notification preferences. See How notifications work. Creating a monitor for a saved search
You create your own monitors on top of saved searches. A saved search defines which traces you care about; the monitor decides when that pattern is worth an alert.
There are two ways into the create flow:
- From the Monitors page: click the Monitor button in the top-right and pick a saved search inside the form.
- From a saved search: open the Saved searches dropdown next to the search bar on the Traces page. Hover a saved search and click its bell icon for Create monitor (or View monitor if one already watches it), which opens the same form with that search pre-selected.
The create form asks for:
- Name: a human-readable label, e.g. “Tool error spikes”.
- Description: optional; what the monitor is for.
- One or more alerts: each alert is a card where you pick the saved search, the alert kind, the condition, and a severity.
As you fill in an alert, a one-line preview sentence at the bottom of the card restates the configuration in plain English, so you can confirm it does what you intend before saving. For example:
Alerts each time a new trace matching 'Checkout 5xx errors' is detected.
The three saved-search alert kinds
A saved-search alert can watch its search in one of three ways, shown as tabs on the alert card: Match, Threshold, and Escalating.
Match: alert when matching traces start arriving
Use Match when even one matching trace is worth knowing about, for example a saved search for status = 5xx in production.
Alerts each time a new trace matching 'Production 5xx' is detected.
- A burst of 500 matches arriving at once produces one alert, not 500.
- If matching activity is continuous, you’ll get a fresh alert every 5 minutes for as long as it keeps happening, so an ongoing problem stays visible instead of going quiet after the first alert.
- After a quiet period with no matches, the next match opens a fresh alert again.
The 5-minute cadence is deliberate: continuous matching keeps re-surfacing so you don’t tune out and forget the problem is still live.
Threshold: alert at a milestone or a spike
Use Threshold when one match doesn’t matter, but a lot of them do. The threshold row reads as a sentence you complete: Alert when traces are detected … [amount] [comparison] [baseline]. There are three flavors.
Absolute count
A simple count: alert once you’ve seen a set number of matching traces.
Alerts when traces matching 'Production 5xx' are detected 100 times.
Multiplier: relative to a baseline
Spike detection: alert when the current volume rises to some multiple above a baseline you choose. Pick the comparison times more than and then choose the baseline:
- The average of the last N hours/days: the normal-traffic case. Latitude divides the baseline window into 5-minute slices and compares your current rate against the average slice.
- The previous period (yesterday, or the previous week): for traffic that follows daily or weekly patterns, where “normal” depends on the day or time.
Alerts when traces matching 'Production 5xx' are detected 3 times more than the average of the last 7 days.
Worked example. Your saved search averages 20 matches per 5-minute slice over the last 7 days. With a multiplier of 3, the alert fires when the current 5-minute window crosses 60 matches (3 × 20). If your baseline rises to 30/slice next week, the trigger automatically rises to 90, and you don’t re-tune it.
Expected: a baseline that learns your patterns
The smartest option: alert when you’re seeing more traffic than expected for this time of day and week. Unlike average or previous-period, you don’t pick a comparison window at all: Latitude learns what’s normal for each time of day and day of the week on its own.
Alerts when traces matching 'Production 5xx' are detected 3 times more than expected.
How “expected” works. From your trace history, Latitude builds a profile of normal volume for each slot in the week (every hour-of-day × day-of-week pair) together with a tolerance band for how much that volume naturally varies. On each check it compares the current window’s count against the expectation for that slot and fires when the count breaks above the band. Sensitivity sets how wide the band is: a higher value tightens it, so smaller deviations trip the alert. It’s the same seasonal detector that powers the Issue escalating system monitor.
Escalating: alert only when a spike sticks around
Use Escalating when you want to ignore short blips that fix themselves, and only hear about a problem that sticks around. An escalating alert combines any of the threshold modes above with a window:
Alerts when traces matching 'Production 5xx' are detected 3 times more than expected, sustained for at least 15 minutes.
- It’s the measurement window: the condition has to stay true for the whole window, not just for a moment. A single one-minute spike won’t trip it.
- It’s the cool-down: once an incident opens, it stays open until things have been calm for that same window, so it doesn’t rapidly open and close.
An escalating alert can wrap any threshold mode (including a plain absolute count, as below) with that window:
That’s why escalating alerts are the right choice for the kind of thing you’d want to be paged about: short, noisy spikes get filtered out automatically.
Mute, delete, and edit
Mute
Muting a monitor stops it from notifying you, but it keeps recording incidents. Open the monitor and use the Mute / Unmute button, or use the actions menu on the list row. Muting is the right tool for a monitor that’s correct but currently noisy: you keep the incident history for later, you just stop the notifications.
A muted monitor shows the Muted status in the list; a live one shows Live.
Delete
You can delete your own monitors from the list’s actions menu (or remove individual alerts from the details panel). A few rules:
- System monitors can’t be deleted: mute them instead.
- A monitor must always keep at least one alert. When you remove the last alert, the UI offers to delete the whole monitor instead.
- Deleting a monitor stops it firing and hides it from the list. Incidents it already recorded remain queryable.
Edit
What’s editable depends on the monitor type:
| Action | Your monitors | System monitors |
|---|
| Mute / unmute | ✅ | ✅ |
| Rename / edit description | ✅ | ❌ |
| Add / remove alerts | ✅ | ❌ |
| Change an alert’s kind, source, or severity | ✅ | ❌ |
| Edit a condition value | ✅ | Only the Issue escalating sensitivity |
| Delete the monitor | ✅ | ❌ |
How notifications work
When a monitor fires, the incident goes through Latitude’s normal notification system, the same one used everywhere else. Monitors themselves don’t carry notification settings:
- Who gets notified and on which channel is controlled by your per-user and per-project notification preferences, not by the monitor.
- A monitor’s only effect on delivery is its mute state: a muted monitor still records incidents but stops the notifications from going out.
Incidents can be delivered by email and to Slack. Email is toggled per person in notification preferences. Slack is connected once per organization at Settings → Integrations: after you connect a workspace, you route the Incidents group (the Issue discovered, regressed, and escalating notifications, plus monitor incidents) to the Slack channels you choose.
To change channel routing or per-user preferences, use your notification settings rather than the monitor.
Next steps
