Overview

RunDis is an event-driven automation platform. Something happens in a system you already run — an employee is terminated in Workday, CloudWatch raises an alarm, a git tag is pushed — and RunDis decides what should happen next, then does it.

The whole system is six nouns:

Providers → Events → Triggers → Workflows → Steps → Actions

Everything else is detail.

The six nouns

Providers are the systems events come from. A provider is one of three types: an inbound webhook you point a system at, an outbound request RunDis polls on a schedule, or a script it runs. There is no connector catalogue and nothing to request — anything that speaks HTTP is already supported. See Providers.

Events are what a provider ingests. Each one carries the payload the source system sent, and RunDis keeps it so you can see what arrived and what was made of it.

Triggers evaluate rules against incoming events and fire when they match. A trigger owns a tree of AND/OR groups containing conditions, each condition comparing a field in the event against a value with one of eighteen operators. Every evaluation returns a plain-language reason, whether it matched or not. See Triggers and rules.

Workflows run when a trigger fires. A workflow is not a list — it is a directed graph. You declare what each step depends on and RunDis sorts the graph and executes it, so independent branches fan out in parallel and converge again when their dependencies are met.

Steps are the units of work in that graph. A step points at an action, maps input into it from the trigger's event or from an upstream step's output, and carries a policy describing what should happen if it fails. See Workflows and steps.

Actions are the reusable executors a step calls: an HTTP webhook, an email, a Slack message, a script (run in its own container), or an authenticated API call. An action is configured once and used by as many steps as you like. See Actions.

Insights reads the event log to measure one provider: how much is arriving, and whether today looks like a normal day. See Insights. Correlation relates two, answering questions no single system can: HR marked someone as terminated, did the directory disable their account? Each new correlation is published as an event from a built-in Correlations provider, so a trigger can act on it. See Correlation.

What makes this different

Most tools in this category can move data from one system to another. The thing RunDis does that they generally do not is tell you why.

When a trigger does not fire, you do not read run logs and guess. Every condition RunDis evaluates returns a reason string in plain language:

value "terminated" equals "terminated"
value "full_time" not found in [contractor intern]
no array element matched (checked 3 elements)

The same principle carries into run history. When a step does not run, RunDis distinguishes skipped because a condition was false from skipped because something upstream failed — two very different problems that most tools collapse into "did not run".

Where to go next

If you want to see it work, start with the Quickstart: one provider, one rule, one run, in about ten minutes.

If you would rather understand the model first, read Providers, then Triggers and rules, then Workflows and steps, in that order.

Insights and Correlation make sense once events are flowing, so read them after you have a provider connected — there is nothing to look at before then.

The two reference pages — Rule operators and Actions — are lookup tables rather than reading material.