Any system with an API, connected. Any system without one, given one. Windows, Linux, Azure, Google Workspace, the plant-floor server under the desk — integrated into one estate and watched by NightOps — a central monitor with an agent on every server — so the failed night job, the filling disk and the stranded orders are caught before they become a bad month-end. Installed, documented, and handed to your IT team to own.
"It doesn't have an API" is where most integration projects stop. It's where ours start.
REST, SOAP, GraphQL, OData, vendor SDKs. Contract-first mapping, idempotent calls, retries with backoff, every run logged, every reject routed to a person. Microsoft Graph, Google Workspace APIs, HubSpot, NetSuite, SAP, Arena, Windchill — and whatever you run that we haven't met yet.
A read-only API over a legacy database with proper auth and logging. A file-drop watcher that turns nightly exports into events. A scanner or web front end in front of a green-screen transaction. Fourth Shift, FoxPro, Access, AccountMate — there is always a way in, done safely.
Queues so a downstream outage doesn't lose transactions. Reconciliation so both sides tie to the transaction. Monitoring so a feed that goes quiet raises an alert instead of a month-end surprise. The integration discipline →
Most manufacturers aren't one thing. The office is on Microsoft 365 or Google Workspace, the plant runs Windows Server and SQL Server, the newer apps live in Linux containers, and the ERP predates all of it. We work across the whole estate, and the monitoring sits across the whole estate too.
NightOps is the operations platform we built to run overnight and end-of-month processing for manufacturers — and to watch the servers it runs on. A controller is the fleet brain; a small agent on each server reports health, runs and observes the automated batch work, and confirms the outcome, not just the exit code.
The controller holds the schedule for every night and end-of-month run, the approval gates for the steps that shouldn't proceed on their own, the outcome monitors that verify a job actually produced what it should, and the paging. One screen: fleet → host → components → runs → approvals.
The agents are small services on each Windows or Linux server. They report health — CPU, memory, disk growth, services, scheduled tasks, event logs, certificates, backup age — and they run and observe the automated batch operations on that box: ERP night processing, MRP regeneration, invoice batches, print and document queues, backups and restore tests. Virtual agents cover things that aren't a server, like a workflow engine or a cloud service.
Outcome, not exit code. A job that returns 0 but stranded forty orders is a failure. Outcome monitors check the result in the data — orders released, invoices produced, GL batches posted, files delivered — and page when the outcome is wrong, with the log line and the runbook attached.
// illustrative screens. NightOps runs today on Fourth Shift plants' overnight and month-end processing; the same controller-and-agent model installs on any Windows or Linux estate.
Every outage we've ever been called into announced itself first — in a log nobody read, a disk nobody graphed, a job nobody checked. The night job fails silently on Tuesday and surfaces as a bad month-end two weeks later. The disk fills at 3 a.m. and the plant finds out at 6. The backup was running all along; nobody had ever restored one.
The methodology is simple, and NightOps is how it's delivered. Watch the things that predict failure, not just the things that have failed: disk growth rate, job duration drift, queue depth, certificate expiry, backup age. Alert with the evidence attached — the log line, the metric, the runbook link — so the person who gets paged can fix it, not just know about it. Escalate when ignored. Test the restore, not the backup. And log so that root cause is already in the log when you open it: structured, centralized, searchable, retained.
Fixed scope, fixed price after a discovery call. The goal is that your team sees the problem first — not that you depend on us.
Every server, service, job, link and integration that the business depends on — and what happens if each one stops. Usually the first time it's been written down.
The NightOps controller and an agent on every server — plus the metrics and log stack that fits your estate (Grafana, Zabbix, Loki, Sentry, Azure Monitor) feeding it. Night and month-end batch operations registered as runs with outcome monitors. Restore tests scheduled. Dashboards your IT and your plant manager both understand.
Every alert links to the procedure: what it means, what to check, what to do, who to call. Written for the person on call at 2 a.m., not for us.
Your IT owns it, trained and documented. If you'd rather we stay on the alert list, a light retainer covers it. Either way, the next outage is caught on Monday, not discovered on Thursday.
Everything we build ships with this layer already in place — modernized applications, integrations, and Clairvient deployments. This page is for when you want it on the systems you already have.
That one question tells us most of what we need. Then: what runs where — Windows, Linux, Azure, Google, the plant floor — and what has no API but needs one.
You'll get a straight answer and a tight scope. If we can't help, we'll tell you that too — and usually who can.
