Coordinate planned work
Remind the lead before the window opens. Confirm the start. Chase an answer when the window is about to close. Publish start and end notices. All night, on a timer.
Calendar babysitting, every shift
AI operator for the 24/7 NOC
Your NOC, without the night shift.
NOCless coordinates planned work, watches alerts and detects anomalies, and diagnoses and escalates incidents — the repetitive part of a NOC operator's shift. It reads your systems strictly read-only, runs on your own infrastructure or as a dedicated instance hosted in Amsterdam (EU), and by default no message reaches a person until your operator approves it.
- Read-only
- On-prem, air-gapped or hosted in the EU
- Human-in-the-loop
Observer: An Alertmanager alert opens an incident. Investigator: A diagnosis from read-only data: alerts, pods, VMs. Escalator: Finds who is on call and drafts the message. Operator: Approves it. Only then is it sent.
The problem
Three jobs eat every night shift.
A NOC operator on shift does the same three things, over and over, all night. They are essential, repetitive — and none of them requires touching a system.
Watch and correlate alerts
Stare at Grafana, Zabbix and status pages. Deduplicate the storm, connect the three alerts that are one incident, and decide what actually matters at 3 a.m.
Screen-watching, all night
Diagnose and escalate
Pull the logs, check VM and pod state, figure out roughly what broke — then find the right on-call engineer and wake them up with enough context to act.
Lookup before every call
NOCless takes over all three. Your engineers get woken up with a diagnosis, not a pager tone.
How it works
Five agents. One shift. Zero write access to your systems.
NOCless reads what you already run, read-only. Five agents divide the operator's job between them; by default, the only messages that leave are the ones your operator approved.
Reads
read-only, one service account per system
- Alerts — Prometheus / Alertmanager, Grafana, Zabbix, or pushed to a webhook
- Metrics & logs — Prometheus, Loki, Elasticsearch / OpenSearch, CloudWatch, New Relic
- Kubernetes, Proxmox, vSphere
- On-call — NOCless rotas, PagerDuty, Grafana OnCall
- Replies — an IMAP mailbox, opened read-only
Core
PostgreSQL for state, queue and the audit log, and an LLM router
Coordinator
Runs the lifecycle of planned work entered in the console or over the API — reminders, start and end notices, extension requests. A deterministic state machine; the model only reads free-form replies.
Observer
Turns firing alerts — polled, or pushed by webhook — into incidents: one per problem, repeats deduplicated, resolved when the alert clears.
Detector
Runs your checks on metrics and logs — thresholds and seasonal baselines — and, with LLM analysis, groups related findings into one incident.
Investigator
Drafts a first-line diagnosis from read-only data (related alerts, pods and events, VM and host state), marked for a human to check.
Escalator
Finds who is on call for the incident and proposes the escalation, diagnosis attached, for your operator to approve.
Reaches people
only what an operator — or a policy you set — approved
- Microsoft Teams
- SMS gateway
- E-mail (replies come back)
- Slack
The model is used only where reasoning is needed — reading a free-form "give us another hour" reply, drafting a diagnosis, grouping findings. The planned-work lifecycle is a deterministic state machine. That keeps cost, latency and hallucination risk down on critical paths — and it runs on a local model as well as a cloud one.
Trust by design
Deployable where mistakes are expensive.
NOCless was designed for telco and banking environments. The guarantees below are architecture, not configuration.
Read-only by construction
Every integration has its own service account with read-only permissions, and every call is checked against an allowlist before it leaves. There is no write path to your systems — not "disabled", not "restricted". NOCless cannot change them, by construction.
Human-in-the-loop
Every message that reaches a person — a work notice, an escalation — is gated by an autonomy policy. The default is L0: the agent proposes, your operator approves. Autonomy is raised per action type, with data. If you connect a GitHub repository, issues for long-running incidents open on their own — and are audited like everything else.
Audit everything
Every agent decision, every prompt sent to a model, every outbound message lands in an append-only audit log — the app's own database role cannot change or delete it. Months past your retention go to your S3-compatible bucket, checksummed and read back before they leave the database. It is your compliance trail and the evidence base for raising autonomy.
Your metal, or a dedicated EU instance
On-prem on Kubernetes via Helm — profiles for k3s, AKS, EKS and GKE, or your own cluster — with an offline bundle for air-gapped clusters. Or as a service: a dedicated instance hosted in Amsterdam (EU), just for you. Bring a local model (Ollama, vLLM, LM Studio) or your own API key.
Releases you can verify
Images and the Helm chart are signed with cosign and ship with SBOMs, for amd64 and arm64. The licence is checked offline — NOCless never calls home. After every install or upgrade, an install check probes the database, sign-in, each integration and every agent, and says what to fix.
Least privilege, written down
Roles — viewer, operator, admin — come from your single sign-on (OIDC: Keycloak, Entra ID, Okta and others). Outbound calls to cloud-metadata and link-local addresses are refused before they connect. We keep a written threat model of the controls and the open gaps — ask for it.
The autonomy ladder
L0 Proposedefault
The agent proposes every notice and escalation; the operator reviews and approves it. Shadow mode — every rollout starts here.
- Work notices
- waits for an operator
- Escalations
- waits for an operator
L1 Partial
Routine work notices go out automatically; escalations still need operator approval.
- Work notices
- goes out on its own
- Escalations
- waits for an operator
L2 Full
Proposals of that action type go out on their own — escalations included. Every one is still in the audit log.
- Work notices
- goes out on its own
- Escalations
- goes out on its own
Set per action type. You climb the ladder only as the audit log shows the proposals were right — never by default.
Integrations
Reads what you already run.
Every system NOCless watches is reached read-only: one integration, one service account, read-only permissions. Nothing to install on the monitored side.
Prometheus / Alertmanager
Metrics & alerts
read-only
Grafana / Loki
Alerts, metrics & logs
read-only
Elasticsearch / OpenSearch
Logs, with links into Kibana
read-only
Zabbix
Monitoring
read-only
Kubernetes
Pods & events
read-only
Proxmox / VMware vSphere
Virtualization
read-only
AWS CloudWatch / New Relic
Cloud metrics
read-only
PagerDuty / Grafana OnCall
On-call schedules
read-only
Alert webhooks
Alertmanager or Grafana pushes alerts in
inbound only
IMAP mailbox
E-mail replies about planned work
read-only
HashiCorp Vault
Secrets
read-only
Keycloak / Entra ID / ADFS
Single sign-on
read-only
GitHub
Issues that track open incidents
opens issues
Teams / SMS / e-mail / Slack
Notifications
approved messages
S3 / MinIO / Ceph
Archive of past audit months
its own archive
Your custom integration
Built for your systems, with scope agreed individually.
Enterprise
Read-only means a service account with read permissions and an allowlist of calls checked before any request leaves NOCless. What NOCless writes: messages your operator — or an autonomy policy you set — approved; if you connect a repository, GitHub issues that track open incidents; and, if you set up an archive, its own audit months to your bucket.
Does NOCless change anything in my systems?
No. Every integration is strictly read-only — its own service account with read permissions, and no write path to a monitored system anywhere in the codebase. What NOCless sends are the messages your operator — or an autonomy policy you set — approved, issues that track open incidents (if you connect a GitHub repository), and its own audit archive to a bucket you choose. Changing systems is a design boundary, not a setting.
What happens when the model is wrong?
By default no message reaches a person without operator approval: NOCless starts at autonomy level L0, where the agent proposes and your operator approves. Every decision and message is also written to an append-only audit log, so a wrong proposal is reviewable evidence — not an outage.
Can it run air-gapped?
Yes, on Kubernetes. The offline bundle carries the images, Postgres, the Helm chart and checksums for a cluster without internet access — k3s, AKS, EKS, GKE or your own. NOCless runs with a local model (Ollama, vLLM, LM Studio) instead of a cloud API, makes no outbound calls of its own, and checks its licence offline. No data has to leave your network.
Can you run it for us?
Yes. As a service, every customer gets a dedicated NOCless instance — its own database and audit log, nothing shared with anyone else — hosted in Amsterdam (EU), so your data is stored in the EU. If you choose a cloud model, its prompts go to that provider; the subprocessors are listed in the data processing agreement. It reaches your systems the same way it does on-prem — read-only, through the service accounts you give it — over Tailscale: the instance joins your own tailnet, your ACL decides which endpoints it may reach, and you can remove it at any time. We take care of upgrades, backups and keeping it running; your operators use the console as they would on-prem.
Where does my data go?
Alerts, logs and diagnosis context stay inside your deployment — on your infrastructure, or in your dedicated instance in Amsterdam; state and the audit log live in its PostgreSQL. What leaves is what you configure: approved messages to your channels; GitHub issues for open incidents (redacted), if you connect a repository; past audit months to your own bucket, if you set up an archive; and — only with a cloud model — the prompts to that provider. With a local model, even prompts never cross your perimeter.
What is NOCless not?
It is not an auto-remediation bot. It will not restart your pods, roll back a deploy or "fix" anything — no such action exists in the product. A human always makes the fix decision; NOCless hands them the diagnosis.
What does it cost?
NOCless is priced per monitored Kubernetes or OpenShift cluster, never per user — DEV, QA and PROD clusters count the same, and support and updates are included. Outside Kubernetes, the offer says what one environment is. Before you commit, a pilot runs for one month at no cost, starting at L0 in shadow mode. Book a demo and bring your hardest shift.
See a shift run itself.
Thirty minutes, your scenarios. We will show you the console, the autonomy ladder and the audit log — and where the write access would be, if there were any.
Book a demoBuilt by Bitflip. Early access — shaped with design partners.