Skip to content

Automation

Open in the platform

The Automation module makes the platform resolve, not just warn. Instead of raising yet another alert that depends on a manual response from your team, SpecialOne triggers the fix on its own: when an alert fires, when a ticket comes into a category you defined, or at the time you scheduled, a resolution routine runs inside your environment and returns the result. It is observability closing the loop, detecting and acting at the same moment, turning repetitive manual work into auto-remediation.

Reach it under DevOps → Automations.

Want to jump straight in?

The Ready-made examples page has complete, copy-and-tune recipes (restart a Windows service from scratch, handle a ticket automatically, scheduled cleanup). If you prefer learning by doing, start there.

The five pieces (and how they fit)

The module has five concepts. On their own they do nothing, the value is in how they connect:

flowchart LR TRG[Trigger<br/>alert, ticket, schedule]:::gat AUTO[Automation]:::auto AGT[Automation agent<br/>runs in your environment]:::agt RB[Runbook<br/>Python or Ansible script]:::rb EX[Execution]:::ex TRG --> AUTO AUTO -->|dispatches| AGT AGT -->|runs| RB AGT -->|reports| EX classDef gat fill:#fee2e2,stroke:#dc2626,color:#7f1d1d classDef auto fill:#6400df,stroke:#4a00b3,color:#ffffff classDef agt fill:#f0e6ff,stroke:#6400df,color:#1e293b classDef rb fill:#ffffff,stroke:#64748b,color:#1e293b classDef ex fill:#dcfce7,stroke:#16a34a,color:#14532d
  • Automation agent: a lightweight service that runs inside your environment (a Docker container) and puts the automations to work. It never opens a port: it only makes outbound connections to the platform, pulls the work that belongs to it, and runs locally. Your secrets (SSH key, database password) stay on it, the platform never receives them.
  • Runbook: the script the agent runs, in Python or Ansible. Your library of ready-made tasks (restart a service, clean disk, create a user).
  • Automation: links a trigger to a runbook on an agent. "When the high-CPU alert fires on host web01, run the restart-service runbook on agent web-agent."
  • Schedule: instead of an alert trigger, runs the runbook at fixed times (every N minutes or daily at 3am).
  • Execution: every time a runbook runs it becomes an execution, with full log, status and origin. It is your history and your audit.

The automation agent is not the monitoring agent

They are two different things. The monitoring agent (see Install agent and collector) collects metrics from your hosts. The automation agent in this section executes scripts. One observes, the other acts. Separate installs and screens.

Two end-to-end paths

Automation starts from two different triggers. It is worth seeing both, because that is what shows the range of what you can do.

Path 1: an alert becomes a fix (auto-remediation)

  1. Monitoring detects that the nginx service went down on host web01 and fires a Critical alert.
  2. You have an automation set up: "service alert in the web* group, Critical severity, run restart-service".
  3. The automation triggers the agent running in that client's network.
  4. The agent restarts the service and reports back.
  5. The result becomes an execution with the whole log, visible in Executions and rolled up in the Report.

Nobody was woken up at 3am. The service came back on its own and everything was recorded.

Path 2: a ticket is handled on its own

  1. A user opens a ticket in the "Service restart" category asking to restart the application on host app02.
  2. You have a ticket automation set up on that category, wired to the agent and the runbook.
  3. As soon as the ticket enters the scope, the automation triggers the agent, passing the ticket number.

  4. The agent runs the action and replies on the ticket itself, with a public comment and an updated status:

    SpecialOne Automation · moments ago

    Service restarted successfully on app02 at 2:07pm. Run time: 3s. Ticket resolved automatically.

The requester gets the answer in seconds, the analyst never had to touch it, and the trail is complete. The step-by-step for this recipe is in Ready-made examples → Handle a ticket.

Who uses it

  • SRE and on-call: build auto-remediations for the most repetitive alerts, cutting manual work and downtime.
  • Support and operations: maintain the runbook library (restart service, drain queue, reset session) and run on demand when they need to act on a host.
  • Systems administration: use schedules for periodic routines (cleanup, collection, sync) without cron scattered across machines.

Where to start

  • Create the agent

    First step: generate and install the agent that runs in your environment.

    Automation agents

  • Write a runbook

    The Python and Ansible scripts, with examples for Linux and Windows.

    Runbooks

  • Build the automation

    Link trigger and action, run on demand, schedule and follow up.

    Automations

  • Ready-made examples

    Complete copy-and-tune recipes, from zero to working.

    Examples