Customer-Owned Monitoring

Client-side monitoring without a third party in your runtime.

Managed script-monitoring services watch your pages from their cloud, with their agent in your DOM and your telemetry on their servers. JavaScript Obfuscator ships the same detection layer as a tool you operate: your pages, your collector, your data.

Open Dashboard Monitoring Runtime Defense PCI DSS Guidance
What You Keep

Ownership is the feature.

Every piece of the monitoring path can terminate in infrastructure you control.

Your runtimeSignals come from your own protected output, not an injected vendor script.
Your dataBeacon to the hosted intake, your own endpoint, or a collector you run.
Your processConfirmed events route into the SIEM and on-call process you already have.
The Detection Layer

What the monitoring actually watches

Four signal families, all emitted from code you ship, none requiring a vendor script in the page.

Tamper and integrity

Runtime Defense raises events when protected code is modified, debugged, or executed outside its locks. See the Runtime Defense docs for the full check list and response actions.

Environment integrity

Hooked-builtin detection, cross-realm comparison against a pristine realm, and headless or automation signals - the checks aimed at scripted analysis. Details in environment integrity.

Script inventory

A source-free audit of what actually runs on a page: first-party, third-party, and unexpected additions. This is the "know what is there" half of payment-page requirements.

Managed web integrity

Policy-driven integrity expectations for the pages you declare, with violations reported through the same event pipeline. See managed web integrity.

Hosted Service vs Owned Tool

The same category, a different custody model

Managed client-side security is a real category with real value - a staffed team watching your pages. The trade is custody: their script in your runtime, your telemetry in their cloud. This is the other answer.

Question a reviewer asks Managed monitoring service Self-hosted monitoring here
What runs in the page? The vendor's monitoring agent, alongside your code. Your own protected output; the checks are embedded in it.
Where does telemetry go? The vendor's cloud, under the vendor's retention policy. An endpoint you choose - hosted intake for triage, your collector, or one you operate. Relevant for data-residency constraints.
Who watches it? The vendor's staffed service, on the vendor's cadence. Your team, through dashboard triage and your own SIEM and on-call routing.
What does an assessor see? The vendor's compliance reports. Inventory, incident rows, and per-incident evidence export from systems you own - supporting evidence for PCI DSS 4.0 payment-page requirements.
What happens if you leave? The history lives with the vendor. The history is already in your systems.
The Operating Loop

From signal to evidence in four steps

The same flow the Runtime Defense evidence path documents, read from the ownership angle: at every step there is a variant that keeps the data with you.

1. Token per surface

Create a monitoring token per app, environment, or release channel, so one collector can be rotated or disabled without touching the others.

2. Choose the intake

Point the opt-in beacon at the hosted dashboard, your own endpoint, or the downloadable customer-operated collector. Unset means no runtime request at all.

3. Triage and export

Filter active and high-severity incidents, work rows through Reviewing to Resolved, and export the view as CSV/JSON or a single incident as Evidence JSON.

4. Route and retain

Confirmed events go to your SIEM, Splunk, Elasticsearch, Slack, or a signed webhook. Retention, alerting, and ownership stay in your process.

Dashboard Monitoring Security Evidence Hub On-Premises Delivery
Who This Fits

Built for teams that cannot add another vendor to the page.

Payment pages counting scripts for an assessor, regulated apps with data-residency clauses, and security teams that already run a SIEM: the constraint is the same - detection is wanted, a new third party in the runtime is not.

Test Protection Security & Trust View Plans
Common Questions

Self-hosted monitoring, answered plainly

Including the questions where the honest answer is a trade-off, not a feature.

How is this different from a managed client-side security service?

A managed service places its agent in your pages and holds your telemetry on its infrastructure. Here the hooks are part of your own protected output, the beacon endpoint is yours to choose, and retention lives in systems you already operate. You trade a staffed service for ownership.

Does this help with PCI DSS 4.0 requirement 11.6.1?

It supplies the technical detection and a reviewable evidence trail: inventory, integrity signals, and export for assessor review. It does not by itself make you compliant — 11.6.1 also requires an operating review process, which stays yours. Full guidance: PCI DSS and JavaScript.

Where does the monitoring data live?

Where you point it. Hosted intake for first triage, your own endpoint, or the customer-operated collector — then onward into your SIEM or webhook. Long-term custody never has to leave your infrastructure.

Do I need the obfuscator to use the monitoring?

The signals ship inside protected output, deliberately — a monitoring hook in readable code is trivial to remove. Script inventory audits, though, run source-free: taking stock of a page does not require protecting it first.

Is there a staffed SOC watching my alerts?

No, and that is the honest trade. If you want a person watching dashboards, that person is yours — which is exactly what buyers with vendor-count or data-residency constraints are asking for.