Quick Start

From zero to first automated resolution in under 5 minutes.

1. Install the Onicis Agent

The agent is a lightweight Windows Service that monitors machine metrics and executes remediation commands. Install it on any machine you want Onicis to monitor.

# Run as Administrator in PowerShell
onicis agent install --org <your-org-token>

# Verify the agent is running
onicis agent status

The agent connects to the Onicis backend immediately and begins emitting CPU, memory, disk, and network metrics. No further configuration is needed.

2. Connect your helpdesk

Go to the Integrations page and connect your helpdesk (Zendesk, Freshdesk, Movidesk, or Milvus). Onicis will start ingesting tickets and classifying them with AI automatically.

3. Push your first runbook

Create a .orb file and push it. Onicis registers the runbook and begins matching it against incoming tickets and metric events.

# disk_full.orb
name: disk_full
version: "1.0"
trigger:
  metric: disk_usage
  threshold: 90

phases:
  diagnostic:
    steps:
      - identify_large_directories
      - list_stale_logs

  remediation:
    steps:
      - clear_temp_files
      - compress_old_logs

  validation:
    steps:
      - assert_disk_below_80
      - emit_resolved

onicis runbook push disk_full.orb
# ✓ Registered: disk_full (v1.0)

4. Watch it resolve automatically

When disk usage crosses 90% on any monitored machine, Onicis fires the runbook — diagnoses the cause, clears space, validates the result, updates the ticket, and marks it resolved. Zero human intervention required.

How It Works

The three-phase automation cycle that every runbook follows.

Every Onicis automation runs the same deterministic cycle. There are no opaque AI actions — each step is explicitly defined in the runbook, making the system fully auditable and predictable.

Onicis never skips phases. If the diagnostic fails, remediation won't execute. If validation fails, the incident is escalated to a human technician — the system never silently gives up or marks a ticket resolved without confirmation.

AI vs. automation

Onicis uses AI to classify tickets and recommend the right runbook, but the execution itself is always deterministic code. This separation ensures that critical actions (account changes, network config) are gated behind human approval while routine remediations run automatically.

The ORBEL Format

Open Runbook Specification Language — plain YAML, version-controlled like code.

ORBEL (Open Runbook Specification Language) is the YAML dialect Onicis uses to define automation workflows. Each .orb file is a self-contained, version-controllable runbook that can be stored in Git alongside your infrastructure code.

Full schema

name: <runbook_id>         # unique identifier, snake_case
version: "1.0"             # semantic version string

# Trigger block (omit for manual-only runbooks)
trigger:
  metric: <metric_name>    # cpu_usage | disk_usage | memory_usage | network_unreachable
  threshold: <number>      # percentage or absolute value
  duration: <duration>     # e.g. 5m — must be sustained this long before firing

# OR schedule trigger
trigger:
  cron: "0 6 * * *"        # standard five-field cron expression

phases:
  diagnostic:
    steps:
      - <step_id>           # built-in or custom step identifier

  remediation:
    steps:
      - <step_id>

  validation:
    steps:
      - <step_id>

Metric triggers

# Fire when CPU stays above 90% for 5+ minutes
trigger:
  metric: cpu_usage
  threshold: 90
  duration: 5m

# Fire when disk usage exceeds 92%
trigger:
  metric: disk_usage
  threshold: 92

# Fire when a service stops
trigger:
  event: service_stopped
  service: spooler

Cron triggers

# Run every day at 06:00 (e.g. certificate expiry check)
trigger:
  cron: "0 6 * * *"

# Run every Monday at 08:00 (e.g. weekly cleanup)
trigger:
  cron: "0 8 * * 1"

Version control

Store runbooks in Git alongside your infrastructure code. Use onicis runbook push in your CI pipeline to deploy new versions automatically.

runbooks/
  disk_full.orb
  cpu_runaway.orb
  ssl_cert_expiry.orb
  outlook_sync.orb
  user_unlock.orb

# In your CI pipeline
onicis runbook push runbooks/disk_full.orb
# ✓ Updated: disk_full (v1.0 → v1.1)

Safety gates

Actions are classified as automatic (run without approval) or restricted (pause and wait for technician approval). The classification is enforced by the platform, not the runbook author.

# Automatic — no approval required
restart_service          clear_temp_files
flush_dns                compress_logs
reconnect_wifi           restart_application

# Restricted — require human approval
modify_security_policy   disable_user_account
change_network_config    delete_files
reset_password           grant_permissions

Self-Healing Infrastructure

Proactive remediation — fix problems before users open tickets.

Self-healing shifts IT operations from reactive to proactive. The Onicis Agent continuously monitors machine metrics and fires events when thresholds are breached, triggering the appropriate runbook automatically — often before users notice the problem.

Architecture

Machine
  │ metrics (CPU, memory, disk, network, services)
  ▼
Onicis Agent                    ← runs as Windows Service
  │ events
  ▼
Onicis Core
  ├── Event Engine               ← receives and routes events
  ├── Rule Engine                ← matches events to runbooks
  ├── Workflow Engine            ← executes the matched runbook
  └── Automation Logs            ← full audit trail

Automation levels

Example scenarios

# High CPU
metric: cpu_usage > 90%  →  identify process → terminate → validate

# Disk full
metric: disk_usage > 90%  →  find large dirs → clear temp → compress logs

# Service crash
event: service_stopped  →  restart service → assert running → emit resolved

# Network failure
metric: network_unreachable  →  reset adapter → flush DNS → renew IP

Automation Catalog

20+ built-in workflows covering the most common enterprise IT support scenarios.

Onicis ships with a library of pre-built runbooks. Each workflow follows the diagnostic → remediation → validation pattern and can be customized or replaced with your own .orb files.

Access & Identity

Performance

Network

Email & Communication

Software & Devices

CLI Reference

Primary interface for engineers, DevOps, and CI/CD pipelines.

The Onicis CLI follows the same philosophy as Docker, Terraform, and kubectl — fast, composable, and CI/CD friendly. Every portal feature is accessible via the CLI.

Agent

onicis agent install --org <token>    # install agent as Windows Service
onicis agent uninstall               # remove agent from this machine
onicis agent status                  # show health, uptime, and connected org
onicis agent logs                    # tail agent execution logs
onicis agent update                  # update agent to latest version

Runbooks

onicis runbook push <file.orb>        # register or update a runbook
onicis runbook list                  # list all registered runbooks
onicis runbook run <name>            # execute a runbook manually
  --machine <id>                     #   target machine ID
  --dry-run                          #   simulate without making changes
onicis runbook logs <name>           # show execution history
onicis runbook delete <name>         # remove a runbook from the platform

Machines

onicis analyze <machine-id>           # full diagnostic report + suggested runbooks
onicis machines list                 # list all monitored machines
onicis machines inspect <id>         # current metrics (CPU, mem, disk, network)
onicis machines remove <id>          # stop monitoring a machine

Incidents

onicis incidents list                 # active incidents
onicis incidents history             # past incidents with resolution details
onicis incidents resolve <id>        # manually mark an incident resolved
onicis incidents escalate <id>       # escalate to connected helpdesk

Interactive diagnosis example

Running onicis analyze returns a structured report and prompts for action:

$ onicis analyze PC-042

Diagnostic Report — PC-042
──────────────────────────
CPU:     73%   ⚠  elevated
Memory:  91%   ✗  critical
Disk:    58%   ✓  ok
Network: 42%   ✓  ok

Issues detected:
  • High memory — zombie processes consuming 4.2 GB
  • CPU sustained above 70% for 18 minutes

Suggested runbooks:
  [1] memory_pressure_handler
  [2] cpu_spike_analysis

Execute remediation? [1/2/skip]:

Integrations

Onicis works on top of your existing helpdesk — no migration required.

Connect Onicis to your helpdesk via a provider adapter. Each adapter handles ticket ingestion, AI classification, and automated responses. You can switch providers without changing any of your runbooks.

How it works end-to-end

1. New ticket arrives in your helpdesk
2. Onicis receives the ticket via webhook
3. AI classifies the issue type (e.g. "printer_issue", "disk_full")
4. Matching runbook is identified and queued
5. Agent executes diagnostic + remediation on the target machine
6. Execution result is posted as a comment on the original ticket
7. Ticket is automatically resolved — or escalated if remediation fails

Connecting a helpdesk

Go to Integrations in the portal, select your provider, and enter your API credentials. Onicis immediately starts receiving and classifying new tickets. Existing open tickets are not affected.