IoT monitoring platform and dashboards, built by us

Every ZARC tag reports through a ZARC Gateway into the same platform, whatever it measures: temperature, pressure, level, leaks, power, doors, sound or the alarm output of equipment already on site. A customer who starts with one solution adds the next to the same gateway and the same dashboard, so the estate grows without a second system to learn. Every site, sensor and gateway shows its live state, its history and when it last reported.

Each platform can be tailor-built around your specific solutions and estate: the views your teams need, grouped the way you run your sites, with the readings and limits that matter to each one. An estates team, a NOC and a site manager can each work from their own view of the same data. Where a requirement is new, we build the dashboard for it, because the team that writes the firmware also writes the software that displays what the firmware reports.

Each reading is checked against the limits set for that sensor as it arrives. When one is crossed, the dashboard raises the alert and sends it by SMS and email to the named people for that site, with acknowledgement and escalation to further contacts if the first person does not respond, and an app on request. A tag that stops reporting raises its own alert, so silence is never read as all clear. How the real-time alerting is secured and recorded is covered on our data platforms page.

The platform is multi-tenant. A partner sees all of its clients, each client logs in to see only its own sites, and within a client, access can be set per team or per site. The same platform runs a single building, a national portfolio, or monitoring that a reseller sells to its own customers under its own brand through the channel partner programme.

Platforms are hosted at the level your data security needs: enterprise cloud infrastructure, dedicated Postgres servers for a single client, or servers on your own site where data must not leave it. Encryption, role-based access and audit logging are built in at every level, and the detail is on our secure IoT data platforms page.

IoT Technologies takes the building of its software platforms very seriously. Security is not a feature we add at the end; it is the first constraint every decision has to pass. We treat nothing as trusted by default: not a device, not a network, not a user, and not our own tooling.

A gateway or sensor is unknown to the platform until it has been deliberately registered to a specific customer and site, and until then anything it sends is held aside and never reaches a dashboard, an alert or a report. Every message must identify itself consistently with the channel it arrives on. Readings are accepted only for the fields that type of device is permitted to carry, and anything that does not conform is quarantined for inspection rather than silently discarded or silently believed. Ownership of data follows the device, never the network path it happened to take, so information cannot drift between customers because of how it was routed.

Every customer sits behind two independent walls. The application checks who you are and what you may see on every page, request and export, and the database itself enforces the same boundary row by row, so a fault in one layer is still stopped by the other. We prove that separation continuously with a permanent test customer whose only job is to try to see someone else's data and fail.

Our environments are segregated, not merely separated: staging and production share no infrastructure, credentials or networks with each other or with any other platform we operate. Every secret is generated fresh for the environment it serves and never copied. Administrative access is by cryptographic key only, with password login disabled, and firewalls deny by default.

Every failure that matters, from an unusual pattern of sign-in attempts to a service that stops, is routed to a person rather than to a log nobody reads. Sign-in is protected by multi-factor authentication, rate limiting and alerting. Logs refer to people and records by identifier, never by personal detail. When something goes wrong, the user is told so and given a reference, and is shown nothing about the system behind it.

How we build matters as much as what we build. Every automated tool in our engineering process is governed more tightly than most teams govern people and works under least privilege. These tools can propose and test code, but they cannot reach production credentials, cannot deploy, cannot change their own permissions and cannot approve their own work. Where they can see live systems at all, it is through a narrow gate that answers a handful of read-only questions and refuses everything else.

Every change is a single, small, named unit of work with a written scope and a recorded reason, and a reviewer reads the actual code, not a summary of it. Nothing enters the main codebase without passing automated gates on the exact version being merged: policy checks, tenant isolation tested against a real database, and the full test suite. Nothing reaches customers merely because it was merged. Release is a separate, deliberate step: a rollback point is taken first, the smallest possible part of the system is restarted, and live data must prove the change does what it claims, not just that the service is running. An alarm or failure path is not finished until it has been deliberately triggered end to end and a person has seen the resulting notification.

Dependencies are pinned and reviewed, never upgraded blindly. Designs are drawn and approved before they are built, and built to the approved drawing and nothing more. Every mistake, including the near misses, becomes a written rule that the next piece of work must follow. We also audit ourselves against our own documentation, layer by layer, from the code and the database to the hosts and the release process, and treat any gap between what we claim and what is true as a defect to fix in order of severity.

That is the difference between a platform that has been generated and one that has been engineered: everything on this page is something we can demonstrate, not something we hope.

Every reading, alert and acknowledgement is stored with its date and time, so the platform is also the record for audits, insurers, warranty claims and maintenance planning. Event history can be exported for the systems you already use, and it stays available long after the alert itself has closed.

Most projects start from the solution: the tags, the gateway and a dashboard for the first sites, configured with your limits, contacts and escalation. A proof of concept comes first, then production. From there the dashboard grows with the estate as new solutions and new sites are added, on the same platform and under the same support.