Recurring Maintenance Plans
Maintenance plans can now be scheduled to run more than once.
It’s now even easier to suppress non-actionable alerts during recurring scheduled maintenance.
BigPanda maintenance plans set a rule to suppress alerts that match a specific condition during a scheduled time frame. They are a key tool in reducing noise during known downtimes such as scheduled maintenance or system testing.
The maintenance window defines when a maintenance plan should be applied to incoming alerts. The recurring maintenance plans feature adds additional scheduling options for repeated or recurring maintenance windows.
With this new functionality, you can:
Schedule a single window to recur at the same time on multiple days.
Choose to repeat a window every day, week, or month.
Add an end date to automatically stop the recurring plan in the future.
For example, you can schedule a maintenance plan that will run from today until Dec 31st, that suppresses Splunk alerts from a specific host every Wednesday from 2pm-4pm.
Key Features
Multi-day span: Maintenance windows can now be scheduled for several consecutive days.
New Monthly Recurring Options:
Monthly recurring on a specific day of the month
Monthly recurring based on the relative position of the day within the month (such as Third Friday, Last Wednesday)
Changed API Format: When making API calls, a simplified call structure automatically calculates several
frequency_datafields, using a simpledurationfield. See the API section below for the new call structure.Changed Status Name: We’ve updated status names to be clearer about the plan’s current state:
Planned: The plan is scheduled to run at a future time, but is not currently suppressing alerts.
Running: The plan is currently suppressing matched alerts.
Done: The plan suppressed matched alerts in the past, but is not scheduled to run again.
Timezone Note: We have added a note to provide clarity that the scheduled maintenance window will be based on the user’s local system timezone.
 |
Recurring maintenance plans include additional Define Time Window options while creating or editing a maintenance plan:
Starts - What time and day the plan should first run.
Ends - What time and day the first run plan should end.
Repeat - How often the plan should run. Options are: Does not repeat, Daily, Weekly, Monthly(relative) or Monthly(specific date).
End Repeat - When the plan should stop repeating. For plans that should run indefinitely, choose a date in the far future.
Granular from times
The selection field in the UI uses half-hour segments to simplify scheduling. If you need to configure a schedule window with a more granular time, use the Maintenance Plans V2 API with the Frequency options added (see below).
Time zones and daylight savings
The time zone of a maintenance plan is determined by the browser time zone settings of the user who created the plan. For example, if a user in the EST time zone creates a maintenance plan that starts at 5 AM EST, users in the PST time zone will see the plan begin at 2 AM PST.
Maintenance plans use a fixed Unix epoch time, so plan windows will not adjust for Daylight Savings Time.
Schedule Limitations
For monthly recurring windows with a selected date, the plan will only run in months where that date occurs. When scheduling a window on the 29th, 30th, or 31st, keep in mind the plan may not run every month.
Recurring windows must have an end date. To schedule a plan that should run indefinitely, select an end date in the distant future.
API Support
Recurring maintenance plans are able to be managed with the Maintenance Plans V2 API using the new frequency and frequency_data fields. To create or update a maintenance plan's schedule, include these additional fields in the body of the API call.
Plan run times are calculated automatically from the plan start field. Plan start should be the time when the plan should first run in Unix epoch time. The end of the run window will be calculated from the duration field.
For recurring plans, the end field sets the time when the plan will stop repeating in Unix epoch time.
Additional object parameters will be added in-system upon creation of a maintenance plan. The current_run and next_run fields should not be included in Post or Patch calls.