Automations and continuous testing
Turn one-off assessments into continuous coverage with scheduled and event-driven runs, plus the operational rules around runners and credits.
Manual runs are great for discovery, validation, and one-off questions. Automations are how the platform shifts from "we ran a pentest" to "we have continuous coverage." Each automation stores a goal, a scope, and a trigger; when the trigger fires, the platform creates a real run with the full output (assets, findings, evidence, report) of a manual one.
This page covers the automation model end-to-end: what an automation is, when to use scheduled vs. event-driven triggers, how runner availability interacts with timing, and how credits behave across recurring runs.
What you will learn
- What an automation is. A stored run configuration that fires on a trigger.
- Schedule vs. event. When to use each, and how triggers compose.
- Runner availability. What happens when a private runner is offline at fire time.
- Credits and limits. How recurring runs draw from the credit balance.
Related app areas
What an automation is
An automation is a saved run configuration. It carries a name, a scope, an execution target (cloud or attached private runner), an intelligence category, a goal, and a trigger. When the trigger fires, the platform creates a real run — same plan, same execution, same output as if you had launched it manually.
Once created, an automation can be paused, edited, run on demand, or deleted. Its history shows every fire and the run it produced.
When to use an automation
Use an automation when a goal is stable enough to repeat. If you keep writing the same goal week after week, that is a sign to turn it into an automation.
- Recurring discovery — re-map a scope on a schedule to catch new attack surface.
- Targeted re-assessment — periodically retest a high-value workflow.
- Compliance readiness refresh — keep readiness evidence current ahead of audit cycles.
- Event-driven response — re-run a focused assessment when something changes (e.g., a PR is opened on a mapped repository).
Create a scheduled automation
- 1Open Automations.
- 2Click New automation.
- 3Name the automation after what it does, not when it runs.
- 4Choose the scope it should assess.
- 5Choose cloud or private runner execution.
- 6Choose an intelligence category.
- 7Write a focused goal (treat this exactly like a manual run goal).
- 8Set the schedule (daily, weekly, monthly, or custom cron).
- 9Save and enable.
Triggers
NullSquare supports three trigger types. Pick the one that matches the cadence of the work.
- Scheduled — fires on a cron-style schedule (every Monday at 02:00, the first of the month, etc.).
- Event-driven — fires in response to a platform event, for example a pull request on a mapped repository.
- Manual (Run now) — fires immediately. Useful for testing an automation's configuration before letting the schedule take over.
Runner availability
If an automation needs a private runner and the runner is offline when the trigger fires, the platform defers the run until the runner reconnects (within a grace window). After the grace window expires, the firing is skipped and logged. Bring the runner back online to resume the cadence on the next scheduled fire.
Check runner health, not automation status
An "automation did not run" report is usually an offline runner. Open the runner detail page, confirm the heartbeat, and the next scheduled firing will execute normally.
Credits and concurrency
Automation runs consume credits exactly like manual runs. The platform respects your concurrent-run limit — if a trigger fires while you are at the limit, the new run queues until capacity is available.
When credits run low, automations are paused before the balance is depleted; refill in Settings → Billing to resume them.
Automation history
Each automation has a history of fires, the runs they produced, and the outcome (completed, failed, deferred, skipped). Use it to confirm the cadence, audit changes, and spot patterns when something starts misbehaving.
Pause, edit, and delete
Pause an automation to stop future firings without losing the configuration. Edit to change goal, schedule, runner, or scope. Delete to remove it entirely (history is retained). Pausing during a planned downtime is the recommended way to handle scheduled maintenance.