[BUG] Custom Scheduling for detections

[n3w4z4]

Describe the bug

According to the documentation. It is possible to define a custom scheduling based on an analytic story tag.
Link to the wiki doc: https://github.com/splunk/security_content/wiki/4.2-%E2%80%90-Customize-to-Your-Environment

Since it doesn't seem to be possible to define a custom scheduling for each detection (which sounds way more intuitive), the only solution for having more than 1 scheduling per type of detection is to use that analytic stories tag matching.

However, when adding the same config explained in your wiki, contentctl does not validate since it's not expecting a tag field.

I've found some reference about deprecating this field in your code but then I don't see how is this feature currently implemented.

Summary:

Expected behavior

When trying to create a custom deployment config like this

name: Schedule Credential Dumping Daily
id: bc91a8cd-35e7-4bb2-6140-e756cc46f214
date: '2020-04-27'
description: Schedule Credential Dumping Daily with Email notification to the SOC
author: Jose Hernandez
scheduling:
cron_schedule: '0 0 * * *'
earliest_time: -1d@d
latest_time: -10m@m
schedule_window: auto
alert_action:
email:
message: Splunk Alert $name$ triggered %fields%
subject: Splunk Alert $name$
to: soc@splunk.com
tags:
analytics_story: Credential Dumping

Contentctl complains about having a non existing field called tags.
What should happen is that the detection that uses the analytic story called "Credential Dumping" should be using the custom deployment file with the same matching tag.

Screenshots

contentctl Version:

v5.0.0

Additional context

Add any other context about the problem here.

[ljstella]

Since it doesn't seem to be possible to define a custom scheduling for each detection (which sounds way more intuitive), the only solution for having more than 1 scheduling per type of detection is to use that analytic stories tag matching.

Its actually entirely possible to implement a schedule for each search. You can inline the deployment on each and every detection if you want.

tags:
   ...
tests:
   ...
deployment:
  scheduling:
    cron_schedule: 0 * * * *
    earliest_time: -70m@m 
    latest_time: -10m@m 
    schedule_window: auto 
  alert_action:
    notable: 
      rule_description: '%description%'
      rule_title:  '%name%'
      nes_fields:
        - user
        - dest
    rba:
      enabled: 'true'

When modifying the schedule, keep in mind that you may affect the "skewability" of a search. Here are some docs to keep in mind for that.

[n3w4z4]

Thanks for the incredibly fast response Lou. You are right, so I'll use the deployment field in those alerts that requires a custom schedule. I couldn't find any example of a detection with those fields or anything about this in the documentation. Do you have any tips to help me figure out all the possible values that each file can have? (Detections, deployments, etc) Thanks a lot! El jue, 24 jul 2025, 18:54, Lou Stella ***@***.***> escribió:

…

*ljstella* left a comment (splunk/contentctl#430) <#430 (comment)> Since it doesn't seem to be possible to define a custom scheduling for each detection (which sounds way more intuitive), the only solution for having more than 1 scheduling per type of detection is to use that analytic stories tag matching. Its actually entirely possible to implement a schedule for each search. You can inline the deployment on each and every detection if you want. tags: ... tests: ... deployment: scheduling: cron_schedule: 0 * * * * earliest_time: ***@***.*** latest_time: ***@***.*** schedule_window: auto alert_action: notable: rule_description: '%description%' rule_title: '%name%' nes_fields: - user - dest rba: enabled: 'true' When modifying the schedule, keep in mind that you may affect the "skewability" of a search. Here <https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.2/report-management/offset-scheduled-search-start-times> are some docs to keep in mind for that. — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AONXJ5IPAYJE2GYOKCO2K7T3KEFVJAVCNFSM6AAAAACCJMRYH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJUGE3TQNBSGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ljstella]

At the moment, there's not a lot of current documentation for all the possible values of all the possible fields, this is something we're working to improve.

cc: @pyth0n1c

[pyth0n1c]

To @ljstella 's point, documentation (both at the tool level and at the "what can/should/must I include in a given yml file" level) is a HUGE weakness of contentctl today.
It is something we're actively working on improving and hope to have something straightforward and highly usable within the coming months.