Someone watching the GPUs at 3 a.m.
AI infrastructure has failure modes general monitoring misses: GPU memory pressure, serving queues, stale indexes, and permission syncs falling behind. We monitor them continuously, triage alerts, and escalate per the procedures in your contract.
What we monitor, layer by layer.
| Layer | Examples of signals | Why it matters |
|---|---|---|
| Hardware | GPU memory, ECC errors, temperature, disk health | Early warning of hardware failure |
| Model serving | Time to first token, throughput, queue depth | User-visible latency and saturation |
| AI gateway | Error rates, policy denials, quota exhaustion | Access problems and misconfigured apps |
| Retrieval | Index freshness, ingest failures, query latency | Stale or missing answers |
| Data pipelines | Sync lag, permission sync age | Accuracy of data and access |
| Platform | Certificate expiry, license term, storage growth | Avoidable outages |
Metrics stay inside; we look in.
Monitoring is collected inside your environment. Our engineers view it through the access you grant, or alerts are forwarded through a channel you approve. Metrics and logs can also export to your own monitoring stack and SIEM, so your team sees the same picture we do.
Monitoring signals are operational: counts, latencies, and health states. They do not include prompt or document content.
Triage before escalation.
- 1
Detect
An alert rule fires on a threshold, trend, or failure.
- 2
Triage
An engineer confirms impact and checks related signals to find the likely cause.
- 3
Remediate
Within agreed authority, apply the runbook fix, such as restarting a service or rotating a credential.
- 4
Escalate and report
Notify your contacts as defined in the contract, and record the incident and follow-ups.
What comes with monitoring.
- Alert rules tuned for AI workloads
- Runbooks for common failures
- Escalation paths you define
- Incident records and follow-ups
- Capacity and trend reporting
- Export to your monitoring and SIEM
What happens at each alert class.
Alert classes and the actions engineers may take without asking are agreed in the contract. Response time commitments per class are contract terms too; this table shows the shape, not the numbers.
| Class | Examples | Default authority |
|---|---|---|
| Informational | Storage trending up, certificate due for renewal | Record and include in the next report |
| Degraded | Rising latency on one alias, a connector retrying | Apply runbook fixes, notify your channel |
| Service affecting | Model alias unavailable, gateway errors for a team | Runbook fixes plus immediate escalation to your contact |
| Security relevant | Repeated policy denials from one identity, audit write failures | Escalate to your security contact; no remediation that alters evidence |
Alerts people still read after the first month.
Monitoring that pages on every spike gets muted. During onboarding we run new alert rules in observe mode against your real traffic, then set thresholds from the baseline rather than from generic defaults. Rules that fire without leading to an action are reviewed and either retuned or removed, and every change to a rule is recorded like any other configuration change.
Some of the most useful signals come from Control itself. A sudden rise in policy denials for one agent identity can mean a misconfigured application or a prompt-injection attempt; a gap in the audit log's sequence or a failed verification means evidence is at risk; a license approaching its grace period is an avoidable outage. These are watched alongside hardware and serving metrics, and routed to the right contact on your side.
Questions buyers ask
Is monitoring really 24/7?
Coverage hours are defined in your contract. Round-the-clock coverage is available; some customers choose business-hours coverage with after-hours escalation for critical alerts only.
Do monitoring signals include our prompts or documents?
No. Monitoring uses operational metrics and health data. Prompt and document content is not part of it.
Can we use our existing monitoring tools?
Yes. Metrics and logs can export to your tools, and alerts can route into your incident management process.
What can your engineers fix without asking us?
The contract defines that authority. Typically routine runbook actions are pre-approved, while changes that affect users, models, or policies need your approval.
What do monitoring reports contain?
Alert volumes by class, incidents with causes and follow-ups, capacity trends for GPUs and storage, freshness of indexes and permission syncs, and any alert rules added, retuned, or retired during the period.
How do you monitor air-gapped environments?
Collection and alerting run inside the isolated network, and the Control runtime never sends a heartbeat from air-gapped mode. Alerts reach on-site staff through channels you approve, and our engineers work through escorted or on-site arrangements defined in the contract.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.