maintenance-windows not honored - unwanted alerts sent

[amai2012]

Describe the bug

gatus (5.36.0) fires alerts for an endpoint at 21:15 which is supposed to be in a maintenance-window at night time.

Here are the excerpts from my config.yaml:

default-uptime-daytime: &uptime-daytime
  maintenance-windows:
    - start: "19:40"
      duration: 11h
      timezone: "Europe/Berlin"

default-endpoint_ssh: &defaults_ssh
  interval: 5m
  ssh:
    username: ""
    password: ""
  conditions:
    - "[CONNECTED] == true"
    - "[STATUS] == 0"

default-endpoint_ssh_alert: &defaults_ssh_alert
  <<: *defaults_ssh
  alerts:
    - type: teams-workflows

endpoints:
  - name: "aws-lnx0097"
    url: "ssh://aws-lnx0097:22"
    group: XX"
    <<: [ *defaults_ssh_alert, *uptime-daytime ]

It might be a timezone issue, therefore the start of the maintenance-window is even more than one hour before the target systems shuts down. The timestamps from the running container match the wall clock...

What else could be wrong? yaml merge?

What do you see?

Alert fired at 21:15

What do you expect to see?

No alert fired later than 19:40

List the steps that must be taken to reproduce this issue

No response

Version

5.36.0

Additional information

No response

[amai2012]

#1551 (title misleading) and especially #1804 seem to be related.

[amai2012]

@TwiN Please review the related PR, I spent many hours trying to find a bogus configuration on my side before figuring out it is a bug in gatus.

[wahajahmed010]

Just dove into this — your diagnosis ("it might be a timezone issue… yaml merge?") is on the right track, but the real culprit is neither: it's a validation ordering bug that silently breaks maintenance windows on every SSH and DNS endpoint.

Root cause

In config/endpoint/endpoint.go, Endpoint.ValidateAndSetDefaults() calls the maintenance-window validation loop (lines 253–257 in current master), but for SSH and DNS endpoints it returns early before that loop:

// SSH path
if e.SSHConfig != nil { return e.SSHConfig.Validate() }
// DNS path
if e.DNSConfig != nil { return e.DNSConfig.ValidateAndSetDefault() }

The maintenance-window loop lives after both returns. So for your ssh://aws-lnx0097 endpoint, maintenance.Config.ValidateAndSetDefaults() is never called. That means:

• c.durationToStartFromMidnight stays at the zero value (0).
• c.timezoneLocation stays nil → now is never converted → still in UTC/server-local.
• c.Enabled defaults to nil → IsEnabled() returns true (so the window is "enabled").

When IsUnderMaintenance() runs at 21:15 Europe/Berlin:

• now.Hour() = 21, int(0/1h) = 0 → 21 < 0 is false → adjustedDate stays at today's day.
• startOfMaintenancePeriod = midnight today UTC (zero duration added).
• endOfMaintenancePeriod = midnight today + 11h = 11:00 today UTC.
• now.After(midnight) = true, but now.Before(11:00 today) = false → returns false.

So Gatus thinks the window ended at 11:00 and starts alerting at 21:15, exactly what you're seeing. Your start: "19:40" and timezone: "Europe/Berlin" are completely ignored.

Confirms your observation

You said "even more than one hour before the target system shuts down" — yes, because the start has been collapsed to midnight UTC, the "window" ends ~11 hours later at server-local 11:00, regardless of what your YAML says. That matches "alerts at 21:15" if your server runs in UTC.

Why no validation error on bad start

Side note: because ValidateAndSetDefaults is never reached, a typo like start: "25:00" on an SSH/DNS endpoint is silently accepted instead of returning errInvalidMaintenanceStartFormat. That's a separate-but-related smell from the same bug.

There's already a PR open

#1804 by amai2012 fixes this — moves the maintenance-window loop above the early returns and also fixes the same bug for ExternalEndpoint (which never called the loop at all, per #1551). It includes regression tests for SSH, DNS and external endpoints. Worth a review; the fix is small and the test coverage looks solid.

If you'd rather not wait for the PR, a one-line local workaround is to define the maintenance window at the global maintenance: level instead of per-endpoint — cfg.Maintenance.IsUnderMaintenance() is checked at watchdog/endpoint.go:66 and that path does validate correctly. Slightly less granular but unblocks you today.