Integrations

There is no plugin directory, and that is a decision rather than a backlog item. Everything below is already in the agent you downloaded; pick the row that costs you the least.

Mechanism	How you hook it in	What you get	What you give up
Command wrapper `--wrap`	Put the agent in front of the command your scheduler already calls. No change inside the job.	Start and end time, exit status, total duration, standard error tail, host, and the resolved command line.	No per-step detail. A fifty-minute job is one opaque fifty-minute bar.
Step marks stdout lines	Print `##slatepipe step=load rows=1240912` where the job already logs its progress.	Per-step duration and row counts, so the chart shows which stage grew.	You have to edit the job, and a mark with a typo is dropped with a warning rather than guessed.
HTTP ingest `POST /v1/runs`	One token header and a JSON body from any language. Twelve lines in most of them.	Everything the agent can express, including runs that never had a process of their own.	Retries, clock skew and the spool are now your problem, not the agent's.

cron

The wrapper form is a drop-in. Keep the redirect you already have; the agent reads a copy of standard error without consuming it.

0 2 * * * /usr/local/bin/slatepipe-agent --wrap \
    --pipeline nightly-ledger -- /srv/etl/load.sh >> /var/log/etl.log 2>&1

If the crontab line already ends in || mailx or similar, leave it alone: the agent passes the child's exit code through untouched, so your existing failure mail keeps working while Slatepipe collects the history.

systemd timers

Wrap ExecStart in the service unit. The agent inherits the unit's user, working directory and environment, which is usually what you want for credentials.

[Service]
Type=oneshot
ExecStart=/usr/local/bin/slatepipe-agent --wrap --pipeline fx-rates -- /srv/etl/fx.py
Environment=SLATEPIPE_COLLECTOR=http://collector.internal:7180

One caveat worth knowing before you file a bug: if the timer has RuntimeMaxSec set and the kill lands on the agent, the finish event is written from a signal handler and the stderr tail may be short by a line or two.

Makefile targets

Recipes work the same way, with one wrinkle: make may run targets in parallel, and two agents writing marks to the same terminal interleave. Give each target its own pipeline name and the collector will keep them apart.

load: extract
	slatepipe-agent --wrap --pipeline warehouse-load -- psql -f sql/load.sql

Container entrypoints

Copy the agent into the image and make it the entrypoint, with your old entrypoint as the argument. The usual mistake is forgetting that the spool now lives inside a container that will be deleted in ninety seconds - mount /var/lib/slatepipe or accept that a run lost during a collector outage is lost for good.

SQL-only shops

If the work is a stored procedure called by a database scheduler, there is no process to wrap. Insert into a small table at the start and end of the procedure, then have one wrapped agent run every five minutes to forward new rows over the HTTP endpoint. It is not elegant, it is eleven lines of SQL, and two of our support customers run exactly that.

What we will not build

Per-vendor plugins that read a scheduler's internal database. We tried one in late 2025, it broke on the next patch release of that scheduler, and a plugin that silently stops recording is worse than no plugin at all. If the wrapper cannot see what you need, write to hello@slatepipe.cloud and tell us what the job looks like - two of the three mechanisms above started as exactly that kind of message.