cronable
IT ops automation

Runbooks that run themselves, inside your own network.

Cronable runs your IT workflows from a machine inside your network, where your SSH keys, servers and admin tools already are. Offboard a leaver across every server, triage a page before anyone opens a laptop, and prove last night’s backup can actually be restored. Every run is recorded with live logs, failures retry and then page someone, and secrets stay encrypted on your own disk.

On the canvas

Offboarding, across every server

A ticket moves, and access is removed host by host. Each server gets its own run with its own log, so one unreachable box doesn’t hide the others, and the ticket gets the result.

jobs/it
Integrations

The tools your week is made of

IT work spans a ticket queue, an on-call tool, monitoring and a fleet of hosts you reach over SSH. These are the integrations the workflows below use.

SSH

Runs a command on a remote host with the system ssh binary and a key on your machine: remove a user, restart a service, run a backup script.

Terminal

Runs a command or script on the Cronable machine itself, with secrets injected and the output captured.

HTTP

Calls any API with a stored credential and checks the status code. Use it for uptime checks, or for an admin API that has no dedicated integration.

Jira

Jira

The Jira webhook trigger fires on the events you choose, optionally narrowed with JQL. The action searches, creates and comments on issues.

Integration details
PagerDuty

PagerDuty

The PagerDuty webhook trigger fires when an incident is triggered, acknowledged, escalated, reassigned or resolved. The action lists, reads and creates incidents.

Datadog

Query metrics, list and read monitors, and mute or unmute a monitor around planned work.

Sentry

List issues and their events, and resolve or ignore an issue from a workflow.

GitHub

GitHub

Create issues, add comments or dispatch a workflow, and start a chain on pushes, releases and workflow runs.

Integration details

Cloudflare

List zones and DNS records, create a DNS record, or purge the cache after a deploy.

Claude

Claude (API)

Turns an alert payload or a block of metrics into a short summary a responder can read in ten seconds.

Integration details
Ollama

Local Model (Ollama)

Summarizes logs and alerts with a model on your own hardware. The text never leaves the machine.

Slack

Post the summary, the result or the failure to the channel the team watches.

Integration details

Microsoft Teams

Post the same messages to a Teams channel through a Workflows webhook.

Integration details
Workflows

Four IT workflows, step by step

Each one is a chain of jobs built from real Cronable job types. Every run keeps its status, timing and full log.

Leavers offboarded on every host, with the receipt on the ticket

When an offboarding ticket moves to ready in Jira…

  1. 1The Jira webhook trigger fires for that project, narrowed by a JQL filter.
  2. 2A For each step fans out over your list of hosts. Each one runs as its own job, with its own log.
  3. 3An SSH step runs your removal script on that host: delete the account, revoke the key.
  4. 4A Collect step waits for the last host and counts what succeeded and what didn’t.
  5. 5A Jira step comments the result on the ticket. Any host that failed also posts its error to Slack.

Access comes off everywhere in one pass, and the ticket carries proof of it.

Pages triaged before anyone opens a laptop

When PagerDuty triggers an incident…

  1. 1The PagerDuty webhook trigger fires on incident.triggered and hands the incident down the chain.
  2. 2A Datadog step queries the affected service’s metrics for the last hour.
  3. 3A Local Model (Ollama) step, or Claude (API) if you prefer, writes a short summary of what moved and when.
  4. 4A Slack step posts it to the incident channel. In parallel, a Jira step opens the post-incident review issue.

The responder starts with context instead of a blank dashboard.

Backups you have actually restored

When the nightly backup window opens…

  1. 1A daily schedule at 02:00 runs your backup script over SSH, with three attempts and exponential backoff.
  2. 2Only if that succeeded, a second SSH step restores the backup into a scratch database and checks the row counts. A mismatch exits non-zero and fails the run.
  3. 3On success, a Slack step posts that last night’s backup was verified.
  4. 4On failure, the handler opens a PagerDuty incident with the error, so a broken backup pages someone that night.

You find out a backup is broken the morning after, not on the day you need it.

Certificates and endpoints, watched

When nobody is looking…

  1. 1An HTTP step checks each endpoint every hour and expects a 200, retrying three times before it gives up.
  2. 2A weekly Terminal step runs an openssl check that fails if the certificate expires within 21 days.
  3. 3Each has its own failure handler: the endpoint check posts to Slack, and the certificate check opens a Jira issue to renew it.

Expiry dates stop being a surprise, and an outage arrives as a message, not a customer email.

What changes

What changes for IT

Runbooks stop living in someone’s head, and every execution leaves a trail.

Runbooks that run the same way every time

The steps live in a versioned workflow, not a wiki page. Anyone on the team can see exactly what will run, and on which hosts.

Failures page someone

A job retries, then hands off to a failure handler: Slack, PagerDuty, Jira or email. Nothing fails quietly at 3am.

A log for every execution

Each run keeps its status, timing, output and secret-masked logs, streamed live while it happens. A fan-out keeps one run per host.

Nothing new exposed

Cronable binds to localhost and opens no ports to the network. It reaches your hosts the way you already do: over SSH, from inside your network.

The numbers you report on

  • Mean time to resolve (MTTR)
  • Time to deprovision a leaver
  • Backup restores verified
  • Certificates renewed before expiry
  • Hours spent on routine tickets

We don’t promise figures. Cronable records every run, so you can measure these yourself, before and after.

Questions

IT ops automation, answered

Where do credentials and SSH keys live?

On the Cronable machine. API tokens and passwords are encrypted with AES-256-GCM in a local database and referenced by name, never written into a workflow file. SSH jobs use a key file on that machine, and ssh never prompts, so authentication has to work unattended. Resolved secrets are masked out of logs, output and the live stream.

What happens when something fails?

With a retry policy, a job retries up to 20 times, with fixed or exponential backoff. If it still fails, jobs that depend on its success don’t run, and the failure handler you chose runs instead with the error in hand. A machine-wide default handler catches any job that has no handler of its own, and Cronable can email you whenever a job fails.

Can I prove what happened six months later?

Yes. Run records, with trigger, status, timing and output, are kept with no expiry unless you set one. Per-run log files are kept for 30 days by default, and you can keep them longer. Changes to workflows are commits in a git repository you own, and on Business the audit trail records who changed what in the app.

Who can change a workflow?

On Plus and Business, each operator signs in with their own account. Business adds single sign-on through Okta, Entra ID, Google or Keycloak, role-based access, the audit trail and four-eyes change approval. Turn on exec-tiering and only admins can create or change jobs that run commands, such as Terminal, SSH, Git and the coding agents.

What can the AI do on its own?

The built-in assistant builds workflows from a description. It has no shell, browser or file tool and never sees a secret value. Anything it runs, and any change that could make a job run on its own, asks you to confirm first, and goes through the same roles and approvals as your own changes. An AI step inside a workflow reads text and returns text, and it reaches only the folders, hosts or jobs you explicitly give it.

Does it need inbound access to our network?

No. The engine binds to localhost and reaches out. Webhook triggers from PagerDuty, Jira or GitHub arrive through Cronable’s hosted relay: your machine holds an outbound connection and collects each event, which the relay keeps for up to 24 hours. Webhooks need a paid plan. Remote control works the same way, so no port is opened on your firewall.

Other solutions

AI agentsFinance & accountingE-commerce

Automate your operations.

Cronable is launching soon. Join the waitlist and we’ll email you the moment self-serve accounts — and the apps for Mac, Windows and Linux — go live.

Join the waitlist

If it’s in the runbook, it’s cronable.