What is Obscenter

Obscenter watches a web application from the visitor's browser down to the machine that answers it, and opens a ticket by itself when something stops being normal. You can run it on your own server, or use the hosted install at obscenter.site. It is the same software either way.

What it measures

There are four kinds of source, and each one reports to the same collector:

• A browser tag. One script tag on your website. It measures page loads, Core Web Vitals, the resources each page pulled in, the API calls the page made, JavaScript errors, clicks, rage clicks and scrolling. It can also record sessions for replay. See Install the tag on a website.
• A mobile agent. One file you add to a React Native or Expo app. It reports screens, cold starts, taps, failed requests and crashes. See React Native and Expo apps.
• A server agent. One command on a Linux or Windows machine. It reports processor, memory, disks, network, processes, services, logs and installed packages. On Linux it can also trace Node.js services from inside the process: requests, database queries, outgoing calls and sampled CPU frames. See Install the server monitoring agent.
• Devices. A microcontroller such as an ESP32 posts a small JSON object over HTTP. Nothing is installed on it. See Connect an IoT device.

Other tools can report too. OpenTelemetry traces arrive over OTLP/HTTP, from an SDK directly or through an OpenTelemetry Collector (OpenTelemetry), and a Sentry organisation can be pulled in (Sentry integration).

One story from the click to the query

The parts are linked by measured evidence, not by name matching. When a page calls your API, the browser tag sends a W3C traceparent header. The server agent picks up the same trace id on the other side. The page load, the request that served it and the query underneath therefore become one record. When the page itself is rendered on the server, the trace id comes back on the response, so that case is linked too.

The same rule holds across the product: an aggregate number leads to the sessions behind it, a slow request leads to its trace, and a trace leads to the process and the machine. The topology draws a line between two things only when a measurement connects them.

Problems, not alerts

Every two minutes a detection engine compares what is happening now with what is normal for that thing over the last three days. A ticket opens once, collects evidence while the fault lasts, and closes by itself when the measurement has been normal for 30 minutes. Each ticket names its likely cause from data that is already stored: the machine underneath, the services it waited on, where the time went, what it threw, and what else broke at the same moment. See How problem detection works.

A language model is optional. By default it never decides whether something is wrong. If you configure one, it can write a summary of a ticket on request, answer questions in the AI assistant, or run as a step in a workflow. The install's administrator can also switch on two AI modes for one organisation at a time. The model then reads each new ticket before it alerts, and may open critical tickets of its own. A critical ticket always alerts. See AI modes.

What else is in the box

• Synthetic checks: HTTP checks and real-browser checks on a schedule, including certificate expiry.
• Load tests run with JMeter. Before a run starts you are told what this machine can drive.
• Workflows that react when a problem opens.
• SLOs and error budgets with burn-rate alerting.
• Vulnerability scanning of host packages and Node dependencies against OSV, CISA KEV and EPSS.
• SSH and Windows logon monitoring, and a map of who is scanning your servers.
• A browser terminal to any monitored Linux machine, through the agent, with every session audited.
• Trend analysis, which compares today with the days before it.
• Dashboards and an AI assistant.

How it is built

The server is a single Node.js program with zero npm dependencies. It stores everything in one SQLite database, using Node's built-in node:sqlite and node:http. It needs Node 22.5 or newer and has no build step. The two client libraries, Leaflet for the map and rrweb for session replay, are vendored and served by the install itself, never from a CDN. See Self-hosting Obscenter.

Machines installed before agent 0.96.0 move to the current names on their own at their next self-update: the service, the directory, the command and the drop-ins it wrote. They keep their key, their settings and their history, and nothing has to be re-run. Settings written under older names keep working.

Where to go next

Start with Getting started. It takes you from an empty account to the first visitor and the first machine reporting.