A lot of SOC work isn't triggered by an alert. It happens because the calendar says it should. Someone reviews the noisiest detections every Monday, checks yesterday's warning signals for anything worth hunting, and looks at what the data pipelines are costing before the bill shows up. That work is most valuable when it happens on a steady rhythm, and it's also the first thing that slips when the alert queue gets busy.

Many Anvilogic customers have already turned that work into Blueprints, the orchestration layer of the Agentic SecOps platform that chains AI agents into a repeatable workflow with human approval built in. Until now, though, a Blueprint only ran when someone opened it and clicked Run, which meant the report a team depended on every Monday was only as reliable as the person who remembered to start it.

What launched today

Starting today, any Anvilogic Blueprint can now run on a schedule. The Blueprint's owner decides when it runs, and from then on, it runs on its own, whether or not anyone is online, so the results are waiting when the team starts its day.

That means the recurring work a team has already automated gets done every time, not just on the weeks someone has time to start it. Detections get tuned every week instead of when the noise finally becomes too much, hunts run every morning instead of whenever the queue is quiet, and cost reviews happen before the bill arrives, not after.  Analysts start their shift with finished results to act on rather than a run to kick off, and the time they used to spend starting and checking on runs goes back into the decisions only they can make.

Scheduling and customizing a Blueprint

A schedule is set on the Blueprint itself. The owner picks a cron schedule and a timezone, so a Blueprint can run every few minutes, every weekday morning, or once a week before a standing meeting, on the team's local time. Each scheduled run starts from the same instructions and the same input, so the work is done the same way every time.

Because Blueprints are written in plain language, changing what a scheduled Blueprint does is a matter of editing its instructions, and the owner can change or pause the schedule at any time. The team's own process stays in charge of the work, and the schedule only decides when it happens.

Scheduled runs keep the same controls as every other Blueprint run:

• Permissions carry through. A scheduled run uses the owner's identity and permissions, so it can't do anything the owner couldn't do. It also works with role-based Snowflake search, as long as the owner's Snowflake sign-in is still valid, and the owner gets a warning if it expires.
• Approval gates still apply. When a run reaches an approval step, it pauses until a person approves it, and then it continues.
• Runs don't pile up. Before each run, Anvilogic checks credits and concurrency, and if the previous run is still going, the next one is skipped rather than stacked behind it. Each schedule also has a maximum runtime.
• Every run is on the record. Scheduled runs appear in the Blueprint's run history next to manual runs, with status, duration, credits used, and a summary of what happened. Owners can stop a run, rerun it, or run it immediately, and in-app and email notifications keep the team informed.

How Zendesk is putting detection tuning on a schedule

Zendesk's detection engineering team already produces a weekly report of its noisiest identifiers. The next Blueprint the team is building picks up where that report leaves off. It takes the noisiest identifiers, pulls their results, and runs new detection logic against them to cut search time, weed out false positives, and make each detection more efficient.

‍

‍

The idea at the core of it is logic tuning, rather than allowlisting. An allowlist suppresses results after a search has already done the work of finding them, so it reduces noise without reducing the cost of the search. Zendesk's approach tunes the detection logic itself, so the search looks for exactly what the team cares about, which makes the funnel smaller from the start and means less compute on every run. Allowlisting still has its place as a tuning option, but the goal is a detection that doesn't generate the noise in the first place.

Their team still stays in charge of the changes. The Blueprint's results come back to the Zendesk team as tasks, and the team reviews them, discusses the proposed changes, and decides what ships. Over time, those decisions add up to measurable wins the team can show: faster search times, lower compute costs, and identifiers the monitoring and response team can trust.

Scheduling is what turns this from a project into a habit. On a schedule, the Blueprint can run every week against the latest report, so tuning happens continuously instead of whenever someone has a free afternoon, and the improvements can be tracked week over week.

Build the logic, not the plumbing

Most security teams can now build an agent that does this kind of work, and a prototype that tunes a few detections is a good sign the use case is real. What takes much longer is everything around that agent once it has to run on its own every week: a scheduler, credentials it can safely run under, a plan for when a run hangs or fails with nobody watching, approval steps for anything that changes production, and a record of every run that someone can review later. None of that is the detection logic, and all of it has to be built and maintained before the logic can be trusted to run unattended.

Scheduled Blueprints split that work the way most teams would want it split. Zendesk's engineers wrote the part only they could write, the logic for how their detections should be tuned. Anvilogic runs it, with the schedule, permissions, approval gates, run history, and credit tracking already in place. Teams build on top of the runtime instead of underneath it, and their engineers spend their time on detections instead of on keeping an agent running.

What else teams can schedule

Any Blueprint can run on a schedule, and some of the most common candidates are already in the platform:

• Daily alert tuning. The Daily Alert Tuning Blueprint ranks the 10 noisiest rules from the last 24 hours, picks the best candidate to tune, and recommends a fix based on 30 days of alerts. Scheduled for weekday mornings, it gives analysts a recommendation to approve or pass on at the start of every shift.
• Daily hunting. The EOI Daily Hunt Blueprint hunts across Events of Interest and produces a report of findings and IOCs, without creating alerts or escalations. On a daily schedule, the hunt report is ready before anyone logs in.
• Pipeline cost reviews. The Snowflake Pipeline Cost and Performance Optimization Blueprint inventories pipelines and produces a prioritized report of where to cut cost. On a monthly schedule, cost reviews happen before the bill arrives instead of after it.
• Recurring reports. Weekly tuning reports, coverage reviews, and other standing reports can be ready before the meetings they're built for.

Getting started with scheduled Blueprints

Scheduled Blueprints are available to every Anvilogic customer starting today. Blueprint owners can add a schedule to any Blueprint they own, and every scheduled run shows up in that Blueprint's run history.

Want to see which of your team's recurring workflows are ready to run on a schedule? Talk to your Anvilogic account team to walk through your Blueprints and set up your first schedule.