Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/pixlcore/xyops/llms.txt

Use this file to discover all available pages before exploring further.

This guide provides practical recipes for implementing common patterns in xyOps, from continuous jobs to complex workflow pipelines.

​
Continuous Jobs

A continuous job automatically relaunches itself upon completion, enabling efficient and reliable job execution.
1

Wire Up Completion Actions

Set up actions that trigger the same event upon job completion.
2

Implement Error Handling

If the job fails, create a separate error handler that can:
  • Notify responsible parties about the failure
  • Restart the job if necessary
3

Manage Job Failures

For jobs with repeated failures, prevent system disruption by:
  • Retry Limiter: Establish a maximum limit for retries
  • Retry Delay: Introduce delays between retries for recovery
By following these guidelines, you can create a robust continuous job system that manages execution efficiently and handles errors gracefully.

​
Nightly S3 Backup Workflow

Back up databases and files to Amazon S3 on a fixed schedule with optional retention and notifications.

​
How It Works

Add a schedule trigger for 01:00 in your timezone, and enable catchup so missed runs replay after outages.
Use a workflow to multiplex the job across multiple DB servers:
  • Multiplex Controller: Attach a job node to run on a group of servers (e.g., “Database” group)
    • Use the “stagger” option to spread jobs out, or use Max Concurrent Jobs and Max Queue Limit to run in series
  • Job Node 1: Shell Plugin to create backups on each target DB server
    • Examples: pg_dump or mysqldump, plus tar and gzip for directories
    • Add files to output: echo '{"xy":1, "code":0, "files":["*.tgz"]}'
  • Job Node 2: Upload all input files to S3 (wire via “continue” condition)
    • Target a server with outbound network access
  • Add Max Run Time and Max CPU Limit to the backup job
  • Add Max Concurrent Jobs limit to avoid overlapping runs
  • Add Web Hook or Email action on error and critical with links to the job
Use params and event fields for database credentials and include Secrets where appropriate.

​
Video Transcoding Pipeline with ffmpeg

Transcode incoming videos to MP4 H.264 and push outputs to storage and a CDN. Supports parallel processing with progress feedback.

​
How It Works

Entry: Manual trigger for ad hoc batches or a custom trigger plugin that watches an S3 bucket for new file arrivals. Workflow Graph:
1

Fetch (Optional)

Pull source files into the job input (wire manual run to different start node)
2

Split

Use a Split controller on files so each sub job gets exactly one input file
3

Transcode Job

Shell Plugin runs ffmpeg with a standard preset, writes output to job temp dir, and prints periodic progressExample: Wrap ffmpeg and emit { "xy": 1, "progress": N } updates while parsing ffmpeg stderrAdd files to output: {"xy":1, "code":0, "files":["*.mp4"]}
4

Continue

After all items complete, continue to a packaging step that generates a manifest or index
5

Store

Attach a custom action to upload MP4 outputs to S3 or other storage
Limits: Attach Max CPU Limit, Max Memory Limit, Max Run Time, Max Concurrent Jobs and Max Queue Limit to the transcode node to control resource usage and queue depth. Notifications: On success, fire a Web Hook to your CDN cache purge endpoint. On error, send email or post to a channel.
  • If you need per server fan out, target ffmpeg at a server group instead of a single server, and select “Round Robin” algo
  • Tag successful jobs with transcoded and wire a tag:transcoded action to trigger downstream publishing

​
PostgreSQL Metrics via Monitor Plugin

Collect PostgreSQL health metrics from the CLI and graph them, with alerts and automated remediation.

​
How It Works

Monitor Plugin: Write a simple Monitor Plugin that runs psql and emits one numeric metric per minute. Point the monitor expression at the plugin output. Examples of CLI queries that return a single number: 
# Active connections on a specific database
psql -At -d mydb -c "select count(*) from pg_stat_activity where datname = 'mydb' and state = 'active'"

# Replication lag in seconds on a standby
psql -At -d postgres -c "select extract(epoch from now() - pg_last_xact_replay_timestamp())::int"

# Autovacuum backlog estimate (dead tuples)
psql -At -d mydb -c "select n_dead_tup from pg_stat_user_tables order by n_dead_tup desc limit 1"
In the monitor configuration:
  • Expression: Reference the plugin command output path such as commands.pg_active_conns
  • Data Match: If your plugin returns a line of text, set a regex like (\d+) to extract the number
  • Type: Choose integer or seconds depending on the metric
Alerts: Create alerts that fire when thresholds are exceeded for a few minutes:
  • Active connections above 90 percent of max_connections for 5 minutes
  • Replication lag above 60 seconds for 3 minutes
Actions: On alert, run an event that captures pg diagnostics, or kick off vacuumdb during a maintenance window.
Store database credentials in Secrets and inject via environment or params; do not hardcode.

​
Sunrise and Sunset Trigger Plugin

Launch jobs at local sunrise and sunset with optional offsets. Useful for energy jobs, IoT device control, or time shifting heavy tasks to off-peak windows.

​
How It Works

Trigger Plugin: Implement a scheduler plugin that calculates today’s sunrise and sunset for a configured latitude and longitude. The plugin runs once per minute, compares the current time in a configured timezone, and indicates a launch when a window is hit.
  • Recommended module for Node.js: SunCalc
Parameters: lat, lon, timezone, sunrise_offset_sec, sunset_offset_sec, and optional launch selector (sunrise or sunset or both). Workflow: Wire the plugin trigger node into a workflow that branches on which event fired:
  • At sunrise: Run an HTTP Request Plugin that calls a home automation API to power down exterior lights and open blinds
  • At sunset: Run a batch window starter that increases queue sizes or begins off-peak data processing
  • To avoid dependency on external APIs, embed sunrise calculations in the plugin. Any language is fine.
  • Provide an optional test mode that forces a launch to validate the graph end to end.

​
Daylight Savings Time

Run a job safely during the Daylight Savings Time changeover window without duplicates or missed runs.

​
The Problem

During DST transitions, local clocks jump between 1:00 and 3:00 AM. Two effects occur in many regions:
  • Spring ahead: The clock skips from 1:59 to 3:00 AM. Any time between 2:00–2:59 AM does not exist that day.
  • Fall back: The hour from 1:00–1:59 AM repeats twice. Times in that window occur twice.
Classic Unix/Linux cron uses local time and does not de-duplicate or “catch up” around DST. On spring-ahead days, a 2:30 job is skipped. On fall-back days, a 1:30 job runs twice.

​
The Solution

Use the Max Daily Limit feature to allow a maximum of one job completion per calendar day, then schedule two daily runs:
1

Add Max Daily Limit

Set condition to “Complete” and max daily amount to “1”. This quietly blocks any second run after one job has completed that day.
2

Add Two Schedule Triggers

One at the desired time in your timezone, and a second one exactly +1 hour later.
This arrangement covers all three cases:
  • Normal days: The job runs at the desired time; the +1 hour run is silently blocked by the daily limit
  • Spring ahead: The desired time may not exist (e.g., 2:30). The +1 hour run exists and executes; the daily limit still allows it because nothing ran yet
  • Fall back: The desired time occurs twice; the first occurrence runs and completes, and both the repeated occurrence and the +1 hour run are blocked by the daily limit

​
Example Configuration

The following event configuration runs at 2:30 AM local time, with a safe second attempt at 3:30 AM: Schedule Trigger:
  • Hours: 2 and 3 selected
  • Minutes: 30 selected
  • Timezone: Set to yours
Max Daily Limit:
  • Job Condition: “Complete”
  • Max Daily Amount: 1
Manual runs skip the Max Daily Limit check by design. If you manually re-run the job on a changeover day, it can exceed the daily count.

Build docs developers (and LLMs) love

Get started for freeTalk to us