I set up Freeplay to monitor a new Next.js app, hoping to catch the gnarly edge cases in our chat feature. The Slack alerts started flowing almost immediately — and I mean *flowing*. Every single `console.error` from a misbehaving React hook, every network hiccup, every time someone typed too fast? Straight to the #alerts channel. It went from "oh this is neat" to "mute this channel immediately" in about 48 hours.
The core issue is the default verbosity. It's like they err on the side of sending everything, assuming you'll configure it down. But who has time to triage 200 "errors" that are just noisy client-side logs?
After some digging, I found you can actually make these alerts meaningful. It's just not the default. Here's what I landed on:
* **Severity Thresholds:** The biggest lever. I set mine to only alert on `ERROR` and `CRITICAL` in the Freeplay project settings. Warnings and infos are for the dashboard.
* **Custom Filtering in the Alert Rule:** This is the key. When you edit your Slack alert rule, you can add Lucene-like filters to ignore certain noise. For example:
```json
{
"query": "severity:>=ERROR AND NOT message:*ChunkLoadError* AND NOT message:*webkitAudioContext*"
}
```
This cut out our lazy-loading blips and Safari audio context warnings that weren't actionable.
* **Session Sampling:** Don't need every session? Crank the sampling rate down in your project settings. 100% is overkill for most features.
The real win was combining severity filters with **custom ignored messages patterns**. Now, alerts are actually for things that need a human: unhandled exceptions, failed API calls with user impact, etc.
Anyone else found a good balance? Specifically for front-end SPAs where client-side noise is such a huge factor. What's your filter setup look like?
YMMV
Those filters are a start, but you're still trusting Freeplay's classification. Severity levels are often misconfigured in the source code. A developer's `console.error` for a failed third-party font load isn't an operational `ERROR`.
You need to filter at the source. Instrument your error logging to add a dedicated, machine-readable field for alertable events. Then filter on that. Your alert rule should look for `is_alertable:true AND severity:>=ERROR`.
Otherwise, you're just playing whack-a-mole with symptom strings. The next dev pushes a new "error" message and you're back to square one.
Least privilege is not a suggestion.
Your point about source-level filtering is technically correct, but it requires a level of instrumentation discipline most teams, especially in early-stage projects, don't have. The reality is you're often integrating monitoring *after* the code is written.
A more immediately applicable hybrid approach is to combine semantic filtering at the ingestion point with Freeplay's rules. You can configure the Freeplay SDK or its underlying transport (like OpenTelemetry) to drop or downgrade specific log attributes before they even hit the platform. This moves the filtering upstream from the alert rule, reducing noise volume across the entire project, not just one notification channel.
For your Next.js case, consider processing the logs through a simple middleware function before they're emitted. You can pattern-match and reclassify known noisy errors like `ChunkLoadError` from `ERROR` to `WARNING` there. This gives you centralized control without relying on every developer to adopt a new logging field.