Correction windows

Edit online
You can use correction windows to exclude specific time periods that might cause an inaccurate assessment of your service level objective (SLO) performance. These time periods might include:

  • Planned maintenance windows.

  • Non-business hours (for example, weekends, holidays, or overnight hours).

  • One-off events or incidents that don't reflect normal operating conditions.

By excluding these time periods, you gain a more accurate view of SLO performance and can make informed decisions. This helps avoid inaccurate assessments of your service's overall reliability.

During a correction window, the specified time windows are excluded from the SLO calculation.

  • For time-based SLOs, the correction time window is not counted.

  • For event-based SLOs, all good and bad events in the correction window are not counted.

By excluding temporary events, SLO corrections provide a more realistic and accurate representation of your service's performance, enabling better-informed decisions about your service's reliability and make necessary adjustments.

Corrections can be either a one-time occurrence or recurring on a regular schedule.
  • One-time corrections: Require a specific start time and a duration.
  • Recurring corrections: Use iCalendar recurrence rules. The following recurrence rule parameters are supported:
    • FREQ: How often the correction repeats (for example, daily and weekly)
    • INTERVAL: The gap between each recurrence
    • COUNT: Total number of occurrences
    • UNTIL: Indicates when the recurrence ends
    • BYMONTH: Specific months (for example, January and March)
    • BYDAY: Specific days of the week (for example, Monday and Friday)
    • BYMONTHDAY: Specific days of the month (for example, 1st and 15th)

Creating correction windows for SLOs

Edit online

To create a Correction Window for SLOs, complete the following steps:

  1. From the Instana UI navigation menu, go to Service levels.

  2. Select the Correction windows tab.

  3. Click Create correction window +.

    Note: Alternatively, you can create a correction window directly from a specific SLO dashboard by navigating to that dashboard.

  4. The correction window configuration modal is displayed.

  5. Optional: Define the scope by selecting the SLOs to which this correction window applies. This step is optional and can be completed later.

    • To make a selection, click Add SLO to open the SLO selection modal.
    • In the Add SLOs modal, you can select one or multiple SLOs across different entity types.
    • The side panel on the right shows your selections grouped under each entity type (Applications, Infrastructure, Synthetic tests, Websites) with the count of selected items for each category.
    • Click Add to confirm your selections.
    • You can add more SLOs by clicking Add SLO + or remove existing ones by clicking the remove icon in the Action column.

  6. Configure the start date. You can select a past or future date.

  7. Configure the start time and duration of the correction window:

    • Schedule for all day: Schedules the correction window for 24 hours that begins at 12 midnight on the specified start date. If you enable this toggle, you don't need to configure the Start time and the Duration.
    • Start time: Determines when the correction window starts.
    • Duration: Specifies how long the correction window is active (in minutes, hours, or days).

  8. Select the Correction window recurrence. You can choose one‑time only, daily, weekly, monthly, or yearly. If you select a recurring option, additional form fields are displayed.

    • One time only: This option creates correction window that does not recur.

    • Daily: This option creates correction windows that recur daily. Specify the days on which the window must be repeated, for example, every 2 days.

    • Weekly: This option creates correction windows that recur weekly. For the specified weekly interval, you can define on which days the correction window occurs. Specify the weekdays in the particular week and the weekly interval on how often it must happen, for example, on Friday and Sunday every 3 weeks.

    • Monthly: This option creates correction windows that recur monthly. For the specified monthly interval, for example, every 2 months, you can define on which day the correction window occurs in the following ways:

      • Specify the month-day, for example, the 21st of every second month.
      • Specify the week-day, for example, the second Tuesday of every second month.

    • Yearly: This option creates correction windows that recur on an annual basis. For the specified yearly interval, you can define on which day the correction window occurs in the following ways:

      • Specify the month and day, for example, every year on 25 December.
      • Specify the week-day of a specific month, for example, every last Monday of September.

  9. If the correction window is recurring, configure the Recurrence options:

    • End date: The specific date on which the recurrent correction window ends.
    • Number of occurrences: A total number of times the correction window must recur.
    • Forever: The correction window never ends and keeps recurring.

  10. Configure the correction window name and description.

Correction window calculation examples

Edit online

Understanding how correction windows affect SLO calculations is crucial for accurate performance assessment. The following examples demonstrate the impact of correction windows on both time-based and event-based SLOs.

Example 1: One-time correction window for planned maintenance

Edit online

Scenario: A 2-hour planned maintenance window on 15 March 2025 from 02:00 to 04:00 UTC.

SLO Configuration:

  • Entity: Application
  • Blueprint: Latency (time-based)
  • Target: 99%
  • Time window: Rolling 7 days
  • Total minutes in window: 10,080 minutes
  • Error budget: 10,080 × (1 - 0.99) = 101 minutes

Without correction window:

  • Bad minutes during maintenance: 120 minutes (all 2 hours)
  • Other bad minutes: 15 minutes
  • Total bad minutes: 135 minutes
  • SLO status: 100% × (10,080 - 135) / 10,080 = 98.66%
  • Error budget remaining: 101 - 135 = -34 minutes (depleted)

With correction window applied:

  • Adjusted time window: 10,080 - 120 = 9,960 minutes
  • Adjusted error budget: 9,960 × (1 - 0.99) = 100 minutes
  • Bad minutes (excluding maintenance): 15 minutes
  • SLO status: 100% × (9,960 - 15) / 9,960 = 99.85%
  • Error budget remaining: 100 - 15 = 85 minutes

Impact: The correction window prevents the planned maintenance from consuming error budget, providing a more accurate view of service performance during normal operations.

Example 2: Recurring correction windows for non-business hours

Edit online

Scenario: Exclude nonbusiness hours (10 PM-8 AM weekdays and all weekends) from SLO calculations.

SLO Configuration:
  • Entity: Website
  • Blueprint: Availability (event-based)
  • Target: 95%
  • Time window: Rolling 7 days
  • Timezone: America/New_York

Correction Window Configuration:

Two separate recurring correction windows:

  1. Overnight hours (weekdays):

    • Recurrence: Daily (Monday-Friday)
    • Start time: 22:00 (10 PM)
    • Duration: 10 hours (until 8 AM next day)
    • Excluded per week: 5 days × 10 hours × 60 minutes = 3,000 minutes

  2. Weekends:

    • Recurrence: Weekly
    • Days: Saturday, Sunday
    • Duration: All day (24 hours)
    • Excluded per week: 2 days × 24 hours × 60 minutes = 2,880 minutes

Total excluded time: 3,000 + 2,880 = 5,880 minutes per week

Without correction windows:
  • Total events in 7 days: 50,000 beacons
  • Non-business hour events: 30,000 beacons (60% of total)
  • Non-business bad events: 1,800 beacons
  • Business hour bad events: 400 beacons
  • Total bad events: 2,200 beacons
  • Error budget: 50,000 × (1 - 0.95) = 2,500 beacons
  • SLO status: 100% × (50,000 - 2,200) / 50,000 = 95.6%
  • Error budget remaining: 2,500 - 2,200 = 300 beacons
With correction windows applied:
  • Adjusted total events: 50,000 - 30,000 = 20,000 beacons
  • Adjusted error budget: 20,000 × (1 - 0.95) = 1,000 beacons
  • Bad events (business hours only): 400 beacons
  • SLO status: 100% × (20,000 - 400) / 20,000 = 98%
  • Error budget remaining: 1,000 - 400 = 600 beacons

Impact: By excluding nonbusiness hours, the SLO focuses on peak usage periods when service quality is most critical to users.

Example 3: Recurring daily maintenance window
Edit online

Scenario: Daily maintenance window from 01:00-02:00 every day.

SLO Configuration:

  • Entity: Infrastructure (Host)
  • Blueprint: Saturation (time-based, CPU)
  • Target: 99.9%
  • Time window: Fixed 7 days starting 2025-04-15
  • Timezone: UTC
  • Total minutes: 10,080 minutes
  • Error budget: 10,080 × (1 - 0.999) = 10 minutes

Correction Window Configuration:

  • Recurrence: Daily
  • Start time: 01:00
  • Duration: 1 hour
  • Total excluded per week: 7 days × 60 minutes = 420 minutes

Without correction window:

  • Bad minutes during daily maintenance: 420 minutes (all maintenance periods)
  • Other bad minutes: 5 minutes
  • Total bad minutes: 425 minutes
  • SLO status: 100% × (10,080 - 425) / 10,080 = 95.78%
  • Error budget: Severely depleted (-415 minutes)

With correction window applied:

  • Adjusted time window: 10,080 - 420 = 9,660 minutes
  • Adjusted error budget: 9,660 × (1 - 0.999) = 10 minutes (rounded)
  • Bad minutes (excluding maintenance): 5 minutes
  • SLO status: 100% × (9,660 - 5) / 9,660 = 99.95%
  • Error budget remaining: 10 - 5 = 5 minutes

Impact: The recurring correction window excludes daily maintenance, ensuring only unplanned issues affect the SLO.

Example 4: Correction window with SLO timezone binding
Edit online

Scenario: SLO bound to Europe/Berlin time zone with a correction window for business hours.

SLO Configuration:

  • Entity: Application
  • Blueprint: Latency (time-based)
  • Target: 99%
  • Time window: Rolling 7 days
  • Timezone: Europe/Berlin (SLO is time zone-bound)

Correction Window Configuration:

  • Recurrence: Daily (Monday-Friday)
  • Start time: 09:00
  • Duration: 8 hours
  • Total excluded per week: 5 days × 8 hours × 60 minutes = 2,400 minutes

Important: The correction window uses the SLO's time zone (Europe/Berlin). When the SLO time zone is bound to Europe/Berlin:

  • The correction window start time (09:00) is interpreted as 09:00 Berlin time
  • During Daylight Saving Time transitions, the correction window automatically adjusts with the time zone
  • No manual time zone conversion is needed for the correction window

Calculation:

  • Adjusted time window: 10,080 - 2,400 = 7,680 minutes
  • Adjusted error budget: 7,680 × (1 - 0.99) = 77 minutes
  • This focuses the SLO on nonbusiness hours when the service experiences different usage patterns
Example 5: Event-based SLO with correction window
Edit online

Scenario: Exclude a 4-hour load testing period on 18 April 2025 from 10:00-14:00.

SLO Configuration:

  • Entity: Application
  • Blueprint: Availability (event-based)
  • Target: 99.5%
  • Time window: Rolling 7 days
  • Timezone: UTC

Correction Window Configuration:

  • Type: One-time
  • Start date: 2025-04-18
  • Start time: 10:00
  • Duration: 4 hours

Without correction window:

  • Total events: 100,000 calls
  • Load test events: 25,000 calls (high volume during test)
  • Load test bad events: 500 calls (2% error rate during test)
  • Normal bad events: 200 calls
  • Total bad events: 700 calls
  • Error budget: 100,000 × (1 - 0.995) = 500 calls
  • SLO status: 100% × (100,000 - 700) / 100,000 = 99.3%
  • Error budget: Depleted (-200 calls)

With correction window applied:

  • Adjusted total events: 100,000 - 25,000 = 75,000 calls
  • Adjusted error budget: 75,000 × (1 - 0.995) = 375 calls
  • Bad events (excluding load test): 200 calls
  • SLO status: 100% × (75,000 - 200) / 75,000 = 99.73%
  • Error budget remaining: 375 - 200 = 175 calls

Impact: The correction window excludes artificial load from testing, providing a more accurate measure of real user experience.