Scheduled queries

The canvas is for iteration — you build, run, tweak. Once a query is settled, you usually don't want to keep clicking Run. You want it to fire every morning at 07:00, or once a week, or every hour on the minute, and drop the results somewhere you can pick them up later.

That's what scheduled queries do. A schedule takes a saved query plus a cadence plus one or more APIC connections and produces an unattended execution on Fabrik's Celery workers.

Prerequisites

• The query must be saved. Scheduling a canvas draft isn't an option — the schedule carries a saved-query ID, not an inline graph. Save first (see Saving and sharing).
• The saved query can be a template. If it declares variables, the schedule captures their values at configuration time.

Everything else — filter state, post-processors, pipeline stages, pagination settings — is read from the saved query when the schedule fires. Updating the saved query updates what future runs execute.

Creating a schedule

Scheduled tasks are managed from the Tasks page in the main navigation. New Task opens a dialog that maps one-to-one onto what the backend needs.

Basics

APIC connections

Scheduled tasks run across one or more APIC connections. Tick every connection you want the query to run against — the task forks one execution per connection and each produces its own result record.

This is the unattended analogue of picking an APIC on the Start node: the schedule can hit several fabrics in a single configured run.

At least one connection is required; the task can't save without.

Frequency

Five options; no cron syntax — Fabrik stays friendlier.

Timezone. Schedules resolve in the task's timezone, not the server's. Your user timezone (from Settings) prefills the picker, but you can override per-task — useful when a fabric in another region should run on local business hours.

Variable values (templates only)

When the selected saved query is a template, the form grows a section listing every declared variable. You fill in a value per variable; these get baked into the schedule and re-used on every run. Editing the source template's variable defaults does not retroactively change the scheduled values — the schedule owns its copy.

To change a schedule's values, edit the schedule directly.

Retry

Transient failures (APIC hiccup, network blip, token refresh race) are common enough that retries are a first-class option.

• Enable automatic retry on failure — master toggle.
• Retry count — how many attempts on top of the initial run. Default 3.
• Retry interval (minutes) — wait between attempts. Default 5.

Retries only kick in for failures, not for successful-but-empty results. A query that returns zero rows is still a success.

Log retention

Days to retain logs controls how long this task's execution records stick around before the cleanup job deletes them. Default 30 days. Set it higher for tasks you want to audit long-term, lower for noisy every-minute health checks.

Retention applies to the execution record itself — timestamp, status, row count, error message if any. The result payload can be large; it's kept alongside the record for the same duration.

What happens when a task fires

The Celery beat scheduler polls the database once per minute and compares each task's next_run_at to the current time. When one is due:

1. An execution record is created in pending status — one per APIC connection.
2. Each record is handed to a Celery worker which transitions it to running, opens an APIC session, and runs the saved query's pipeline (optimizer, APIC call, post-processors).
3. The result and row count land on the record; status becomes success.
4. If the query raises, the record is marked failed with the error type, message, and traceback; retry kicks in if configured.
5. The task's next_run_at is recomputed for the next tick.

One task, N connections ticked → N execution records per fire. The Tasks page shows them grouped under the parent task.

The execution history

Every fire leaves a trail. Open a task and the Executions tab lists every run, newest first:

• Timestamp (started / completed).
• APIC connection name (denormalised, so renames don't break history).
• Status: pending, running, success, failed, cancelled.
• Row count returned.
• Execution time in milliseconds.
• Retry attempt number (0 for the initial run, 1+ for retries).
• Error message and traceback for failures.

Click a row and the stored result opens in the same results panel you use for interactive runs — same tabs (Response / Table), same export options.

Status — Active, Paused, Disabled

Three states control whether a task fires.

Pausing is the right tool for "we're deploying tonight, quiet this down for the next few hours." Disabling is the right tool for "we're retiring this workflow, don't restart it."

Permissions

Fabrik's scheduled-task permission model is straightforward:

• Create. Any authenticated user can create tasks against queries they can access.
• Edit / delete. Only the task's creator or an admin.
• Execute on demand. Same as edit — only creator or admin can trigger a manual run.
• View history. Anyone who can see the task can see its executions.

The admin-only special case: system tasks (MIM sync, time machine cleanup, awx polling) are marked is_system_task and can only be edited by admins. Regular users see them in the task list but can't touch them.

Running on demand

Sometimes you want to trigger a scheduled task outside its cadence — for a test run after a schedule change, or to backfill a missed window. The task detail view has a Run Now button that queues the same Celery pipeline the scheduler would use, against all configured connections.

A manual run shows up in the history like any other execution, with a flag indicating it was triggered manually.

Common patterns

Troubleshooting

---

That's the Query Builder. From canvas mechanics through saving, sharing, and scheduling, you now have every lever. The next sections — Class Browser, AWX Automation, Time Machine — build on top of queries: they assume you know how to make one.