Noxtica Pulse: endpoint telemetry overview
Noxtica Pulse is endpoint telemetry and integrity for an organisation’s own applications, such as a game or a workforce program. A small desktop client on the user’s computer reports what your published configuration allows, and Backoffice shows you what is registered, who is enrolled and which configuration is live.
This page is for the administrator or privacy owner who will configure Pulse and for the engineer who connects it to an account system. The other two Pulse pages cover Backoffice configuration and detections, response, devices and privacy.
Key points
- In developmentPulse is not released for deployment to customer machines. This page describes the surfaces for organisations where Pulse is provisioned.
- Configure in BackofficeYou register applications, author profiles and publish signed bundles in Backoffice, never on the player site.
- Published revisions are permanentA published revision cannot be edited or deleted. A rollback publishes older content again as a new, higher revision.
- Small groups are hiddenFleet figures hide groups with fewer than 5 devices to protect individuals, so a small fleet can look under-counted.
What it is
Availability: In development.
Pulse is not released for deployment to customer machines. This page describes the surfaces as they exist for organisations where Pulse is provisioned. It does not offer an installer download or a rollout schedule, and it makes no commitment about operating systems, signing or distribution; agree those with your account team.
The pieces
| Piece | Who uses it | What it does |
|---|---|---|
| Backoffice → Noxtica Pulse | Your administrators | Register applications, author profiles, publish signed configuration bundles, run staged rollouts, review detections and devices, read privacy settings and usage |
| Desktop client | The person using your application | A background service, a tray app and a command-line tool (pulse-ctl). It follows the configuration your bundle sets, shows what Pulse sees, and has a local kill switch |
Player site at pulse.noxtica.com | The person using your application | Register and sign in, authorise the desktop app, see devices and consents, export or delete their data, view and appeal detections |
| Server API | Your backend | Look up a player’s status, issue link codes, unlink, and reverse response hints, authenticated with your server API key |
The player site is a separate site from Backoffice. Tenant staff configure Pulse in Backoffice, never on the player site. While Pulse is in development, treat the player site as available only to organisations where Pulse is provisioned.
How configuration reaches a device
- You register an application. Its slug is the join link every device enrols with.
- You author a profile for it: telemetry, privacy and retention.
- You publish the profile. Backoffice signs it as a configuration bundle with the next revision number.
- Devices pull the bundle on their next poll and verify its signature. A device keeps its last good bundle if a later one is invalid, rolled back or oversize.
- The initial revision of an application goes live for every device at once. Later revisions roll out ring by ring while a health gate stays green.
A published revision can never be edited or deleted. To undo one, you roll back, which publishes the older content again as a new, higher revision.
Telemetry lanes
Devices send telemetry to the ingestion service on ingest.noxtica.com. You do not call these routes yourself.
| Lane | Route | Body limit |
|---|---|---|
| Event batches | POST /pulse/v1/events (pulse.batch/v1) | 256 KiB compressed, 1 MiB decompressed, 500 events |
| Metrics | POST /pulse/v1/otlp/metrics | 1 MiB compressed, 4 MiB decompressed, 500 points |
| Logs | POST /pulse/v1/otlp/logs | 1 MiB compressed, 4 MiB decompressed, 500 records |
| Heartbeat | POST /pulse/v1/heartbeat | 16 KiB |
These lanes are switched off until Pulse is provisioned. Each device authenticates with a short-lived access token that is bound to its own key. Per-device limits default to 60 requests and 1 MiB of compressed uplink per minute. Limits can change; Backoffice → Pulse → Usage shows what the service accepted.
Who sees what
| Role | Can do |
|---|---|
Viewer or higher (view.pulse) | Read overview, applications, profiles, bundles, rollouts, devices, privacy, usage |
Analyst or higher (view.pulseEvidence) | Open a detection or response decision, which shows per-device evidence. Every access is recorded. |
Administrator (manage.pulse, manage.pulseRules, manage.pulseResponse) | Write: register and archive applications, save and publish profiles, roll back, halt and resume rollouts, revoke devices, review detections, accept the response addendum. Every write needs step-up MFA and is audited. |
Prerequisites
- Pulse provisioned for your organisation: the platform switch is on, your workspace is armed for Pulse and entitled to it. Until then the sidebar group is hidden or Backoffice shows “Pulse is not enabled for this tenant. Ask your Noxtica contact to enable it; nothing is collected until then.”
- Viewer role or higher in Backoffice to look; administrator for changes.
- For the server API: a server API key with the scope
read:pulseorwrite:pulse. Create it in Backoffice → Integrations & API → API & SDK. See Authentication. - Legal and privacy review inside your organisation before devices enrol. The pages in this section list controls; they are not legal advice. See Privacy and Security.
Steps
1. Check that Pulse is available to you
Open Backoffice → Noxtica Pulse → Pulse. If you see “Pulse is not enabled for this tenant”, ask your account team. If the Noxtica Pulse group is missing from the sidebar, your role or the platform setting hides it.
2. Read the overview
The Pulse overview shows these cards: Active applications, Archived applications, Active enrolments, Revoked enrolments; Fleet health (Devices reporting, Crash-free sessions, Open detections, Active rollouts); Current revision per application; Rollouts in progress; Attestation level mix; Bundle signer; Device seats and Recent activity. Groups with fewer than 5 devices are hidden from the fleet figures to protect individuals, so a small fleet can look under-counted.
A device seat is one device with an active enrolment, however many applications it is enrolled in. A new device over the seat limit is refused at enrolment; revoking a device frees its seat.
3. Configure Pulse in order
Work through Pulse in Backoffice: applications, profiles, bundles and rollouts: register an application, create and validate a profile, publish it, and follow the rollout.
4. Set review and privacy policy before devices enrol
Read Pulse detections, response, devices and privacy: who reviews detections, how players appeal, what the response ladder may do, and what the privacy page shows.
5. Optional: link players to your own accounts
Your backend can ask for a one-time link code for one of its own users and hand the returned address to that person. The person signs in to the player site, sees what your organisation will see, and approves or denies. See the server API section of the detections page.
Check availability
Open Backoffice → Noxtica Pulse → Pulse; ask your account team if it says Pulse is not enabled.
Read the overview
Applications, enrolments, fleet health, current revision and rollouts.
Configure
Register an application, author and validate a profile, publish it.
Set review and privacy policy
Decide who reviews detections and what the privacy page shows before devices enrol.
Link accounts (optional)
Your backend issues one-time link codes through the server API.
Verify it works
- The Pulse overview loads without “Pulse is not enabled” and lists your registered application under Current revision per application.
- After a device enrols, Active enrolments rises and the device appears under Pulse → Devices.
- After a rollout, the Rollouts page shows the revision, the stage and the last health check.
- Pulse → Usage shows counters per UTC day once devices report.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Noxtica Pulse is missing from the sidebar, or a Pulse address answers “not found” | The platform switch is off, or your role is below viewer | Ask your account team and check your role. |
| “Pulse is not enabled for this tenant” | Your workspace is not armed for Pulse or lacks the entitlement | Ask your Noxtica contact. |
| “Could not load Pulse” | A temporary fault | Retry; contact support if it persists. |
| Fleet health says “Not enough data: every group has fewer than 5 devices” | Small groups are hidden | Wait for more devices; this is a privacy protection. |
| “The warehouse could not be read right now.” | The analytics store is unavailable | Retry later; the figures that did load stay visible. |
| A device is refused at enrolment | The seat limit is reached | Revoke a device you no longer use or ask your account team. |
Server API answers insufficient_scope or tenant_not_armed | Key lacks the scope, or the workspace is not armed | Create a key with read:pulse or write:pulse; ask your account team. |
Who it fits
These are questions Pulse is planned to help answer. Fit depends on what the finished scope turns out to be.
- Is the application behaving as expected? Teams could see whether their application runs as expected on a device, within the signals the tenant enables.
- Is the problem on the device side? Teams could separate a poor device connection from a problem in their own service.
- Which flags deserve human review? Teams could review flagged signals and the evidence behind them before any decision about an account. See Human review is the default.
How teams connect
Tenants and device owners connect to Pulse through the surfaces in The pieces.
- Tenants. Tenants would configure signals, notices and review workflows in the Noxtica console. A tenant would choose which signals to enable for its own application and publish a notice explaining what is collected and why. See Pulse in Backoffice and Pulse detections, response, devices and privacy.
- Device owners. Device owners would sign in with their own Noxtica account on the device, read the notice, and accept or decline optional purposes. They are planned to be able to switch purposes off, withdraw consent, export their data and request erasure. Flagged detections would come with a reason and a way to appeal.
Limits
Read Who it fits and How teams connect as a description of intent.
- Pulse is in development. Nothing on this page is a commitment on scope or date.
- Signals would be indicators, not proof. They are probabilistic and can be wrong. A client running as an ordinary program cannot observe every kind of tampering. The tenant decides what to do, and no protection outcome is promised.
- The client is planned to notify the device owner and report signals. It is not planned to end sessions or stop programs on the device. See Configure the response ladder.
- Customers would be responsible for notices and a lawful basis for their own use. Use on work devices would be off by default and need local legal steps before activation. Watching people without a lawful basis is not permitted.
Common questions
Can I use Pulse today?
No. Pulse is in development. You can ask about early access: see Contact.
Would Pulse run without the device owner knowing?
No. The design goals include a visible indicator, a notice before collection and a view of what is sent. A hidden mode is not planned.
Is Pulse meant for watching people at work?
No. The planned purpose is integrity and performance signals about a tenant’s own application. For work devices, see Limits.
Related
- Pulse in Backoffice: applications, profiles, bundles and rollouts to configure and publish.
- Pulse detections, response, devices and privacy for review, appeals, devices and the privacy page.
- APM and the ingestion service (OTLP) for the separate backend telemetry lanes.
- Authentication and Webhooks for the server API and events.
- Roles and permissions for the capabilities above.