Filter internal traffic

Internal traffic (your team's own visits, office IPs, automated checks) skews every metric. Office machines on warm caches and fast networks look great; mobile visitors in a tunnel look bad; average those two together and the number means nothing.

There's no "ignore my IP" toggle, on purpose; we don't store IPs (see Privacy). The right move depends on what you want to exclude.

Pick the option that fits

Option 1: A separate application for non-production

The cleanest answer for staging, preview, and dev environments.

1. Create a second application in fastmon called e.g. acme-marketing-staging, and set its environment to dev to keep it clearly apart from production.
2. Use its source_hash in your staging deploy. A separate application has its own snippet and hashes; adding the domain as another site under the same application would reuse the production snippet instead.
3. Either ignore the staging application in dashboards, or use it intentionally; staging metrics are useful for catching regressions before production.

Costs you nothing: no client-side logic, no flags, no risk of leaking production data into staging or the other way around.

Option 2: Skip the beacon for internal sessions

Useful for office traffic where the visitor has access to the site's backend or admin UI, and you can mark them as internal there.

The simplest approach: don't render the beacon <script> tag at all when the request comes from an internal session. Server-side render based on whatever "is internal" signal you already have: a session cookie, a JWT claim, an admin login.

{% if not request.session.is_staff %}
  <script src="https://fastmon.site/s/{source_hash}.js" defer></script>
{% endif %}

A client-only variant works too: gate the script-tag injection on a cookie set once when your team hits a /staff route:

<script>
  if (!document.cookie.includes('staff=1')) {
    var s = document.createElement('script');
    s.src = 'https://fastmon.site/s/{source_hash}.js';
    s.defer = true;
    document.head.appendChild(s);
  }
</script>

Option 3: Pause a site entirely

For a maintenance window, an investigation, or a non-production environment that's permanently noisy:

1. In fastmon, open the site, go to Settings.
2. Toggle Active off.

Beacons keep arriving but aren't written to analytics tables. Toggle back on when you want data again. History from when the site was active stays intact.

Option 4: Skip the beacon for synthetic monitors

For Pingdom, UptimeRobot, your own E2E suite, etc., the cleanest move is to not load the script at all. Most monitors set a recognizable User-Agent; gate the script tag on the server side:

{% if request.user_agent.is_synthetic %}
  <!-- skip Fastmon for synthetic checks -->
{% else %}
  <script src="https://fastmon.site/s/{source_hash}.js" defer></script>
{% endif %}

If your stack doesn't have an easy "is bot" check, gate the script tag on a small UA test in your template; same idea.

Verifying the filter

Open your site as an internal visitor. Check DevTools → Network → filter c/. You should see no request to https://fastmon.site/c/.... If you do, the script tag is still being rendered: double-check the gate condition on the server (or the cookie test in the inline snippet).

In fastmon, after the cutover, traffic from your office's country should drop noticeably (country is the only geo dimension we store). If it doesn't, the filter isn't catching those visits.

Common surprises

• You can't filter after the fact. We don't store IPs (see Privacy), so once a beacon's in, we can't tell whether it came from your office. Filtering has to happen at the source.
• The gate runs per page. Make sure the script tag is omitted on every page you want excluded, not just the first one.
• Country-level filters don't help. Your office sits in the same country as most of your real visitors. What works: filtering at the source, where the real context (user, cookie, UA) is still there.

Related

• Sites: separate sites for environments.
• Tracker settings: what the beacon collects.
• Privacy: what we don't collect: why there's no server-side IP filter.