RangeError: Invalid time value in Maintenance Scheduling

sassanix commented 1 month ago

⚠️ Please verify that this question has NOT been raised before.

[X] I checked and didn't find similar issue

🛡️ Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem

I'm encountering a persistent RangeError: Invalid time value when trying to schedule maintenance in Uptime Kuma. Despite ensuring all date and time values in the maintenance table are correctly formatted, the error persists. This issue seems to be related to how dates and times are being processed within Uptime Kuma.

Steps to Reproduce:

Set up Uptime Kuma using Docker with the following docker-compose.yml configuration:

version: '3.8'
services:
  uptime-kuma:
    container_name: uptime-kuma
    image: louislam/uptime-kuma:latest
    volumes:
      - /home/data/kuma:/app/data
    ports:
      - 3001:3001
    restart: unless-stopped

Access the Uptime Kuma interface and attempt to schedule maintenance.

The following error appears in the logs:

RangeError: Invalid time value
    at Date.toISOString (<anonymous>)
    at u.toISOString (/app/node_modules/dayjs/plugin/utc.js:1:1907)
    at Proxy.toPublicJSON (/app/server/model/maintenance.js:76:52)
    at async UptimeKumaServer.getMaintenanceJSONList (/app/server/uptime-kuma-server.js:239:37)
    at async UptimeKumaServer.sendMaintenanceListByUserID (/app/server/uptime-kuma-server.js:226:20)
    at async UptimeKumaServer.sendMaintenanceList (/app/server/uptime-kuma-server.js:217:16)

Database Details:

The maintenance table schema:

CREATE TABLE [maintenance] (
    [id] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
    [title] VARCHAR(150) NOT NULL,
    [description] TEXT NOT NULL,
    [user_id] INTEGER REFERENCES [user]([id]) ON DELETE SET NULL ON UPDATE CASCADE,
    [active] BOOLEAN NOT NULL DEFAULT 1,
    [strategy] VARCHAR(50) NOT NULL DEFAULT 'single',
    [start_date] DATETIME,
    [end_date] DATETIME,
    [start_time] TIME,
    [end_time] TIME,
    [weekdays] VARCHAR2(250) DEFAULT '[]',
    [days_of_month] TEXT DEFAULT '[]',
    [interval_day] INTEGER,
    cron TEXT,
    timezone VARCHAR(255),
    duration INTEGER
);

Troubleshooting Steps Taken:

Verified that all date and time fields are correctly populated and consistently formatted.

UPDATE maintenance 
SET start_date = '2024-07-11', end_date = '2024-07-11'
WHERE start_date IS NULL OR end_date IS NULL;

UPDATE maintenance 
SET start_time = '04:00:00', end_time = '04:15:00'
WHERE start_time = '04:00' OR end_time = '04:15';

Checked for any null values or inconsistencies:

SELECT id, start_date, start_time, end_date, end_time FROM maintenance 
WHERE start_date IS NULL OR end_date IS NULL OR start_time IS NULL OR end_time IS NULL;

Ensured proper ownership and permissions for the database files:

sudo chown -R root:root /home/data/kuma
sudo chmod -R 775 /home/data/kuma

Restarted the Uptime Kuma container multiple times:
```
docker-compose down
docker-compose up -d
```

Logs:

[2024-07-11 10:19:51] RangeError: Invalid time value
    at Date.toISOString (<anonymous>)
    at u.toISOString (/app/node_modules/dayjs/plugin/utc.js:1:1907)
    at Proxy.toPublicJSON (/app/server/model/maintenance.js:76:52)
    at async UptimeKumaServer.getMaintenanceJSONList (/app/server/uptime-kuma-server.js:239:37)
    at async UptimeKumaServer.sendMaintenanceListByUserID (/app/server/uptime-kuma-server.js:226:20)
    at async UptimeKumaServer.sendMaintenanceList (/app/server/uptime-kuma-server.js:217:16)

Environment:

Uptime Kuma Version: latest
Docker Version: 27.0.3
OS: Debian 12
Database: SQLite (included in the /home/data/kuma directory)

Expected Behaviour: The maintenance schedule should be created without errors, and Uptime Kuma should handle date and time values correctly.

Actual Behaviour: The RangeError: Invalid time value error occurs, preventing the creation of the maintenance schedule.

Additional Context: Any insights into why this error might be occurring despite correct date and time formatting would be greatly appreciated. I have followed all recommended troubleshooting steps but have not been able to resolve the issue.

Thank you for your support!

📝 Error Message(s) or Log

[2024-07-11 10:19:51] RangeError: Invalid time value at Date.toISOString () at u.toISOString (/app/node_modules/dayjs/plugin/utc.js:1:1907) at Proxy.toPublicJSON (/app/server/model/maintenance.js:76:52) at async UptimeKumaServer.getMaintenanceJSONList (/app/server/uptime-kuma-server.js:239:37) at async UptimeKumaServer.sendMaintenanceListByUserID (/app/server/uptime-kuma-server.js:226:20) at async UptimeKumaServer.sendMaintenanceList (/app/server/uptime-kuma-server.js:217:16)

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Debian 12 , Docker , Portainer

🌐 Browser

Firefox 127.0.2

🖥️ Deployment Environment

Runtime: Node.js v18.20.2
Database: SQLite (included in the /home/data/kuma directory)
Filesystem used to store the database on: ext4
number of monitors: 9

sassanix commented 1 month ago

I've now tried it on Unraid , and same error on there as well, different operating system with a fresh uptime kuma install.

WarmEthernet commented 1 month ago

I was having the same problem.

Setup: I have Docker running on Ubuntu 20.04 and am running Uptime-kuma version 1.23.13 with 145 monitors.

Things I tried:

Updating kuma from 1.23.11 to 1.23.13
Stopping and restarting the container
Adding timezone to compose file
Changing "Display Timezone" and "Server Timezone" in the settings

Error I was getting: In the GUI I would receive this error - Invalid time value And this was the docker logs:

Trace: RangeError: Invalid time value
    at DateTimeFormat.formatToParts (<anonymous>)
    at a (/app/server/modules/dayjs/plugin/timezone.js:43:22)
    at u (/app/server/modules/dayjs/plugin/timezone.js:46:21)
    at /app/server/modules/dayjs/plugin/timezone.js:98:25
    at o.tz (/app/server/modules/dayjs/plugin/timezone.js:104:14)
    at Proxy.getStatus (/app/server/model/maintenance.js:345:52)
    at async Proxy.toPublicJSON (/app/server/model/maintenance.js:53:21)
    at async UptimeKumaServer.getMaintenanceJSONList (/app/server/uptime-kuma-server.js:239:37)
    at async UptimeKumaServer.sendMaintenanceListByUserID (/app/server/uptime-kuma-server.js:226:20)
    at async UptimeKumaServer.sendMaintenanceList (/app/server/uptime-kuma-server.js:217:16)
    at process.unexpectedErrorHandler (/app/server/server.js:1905:13)
    at process.emit (node:events:517:28)
    at emit (node:internal/process/promises:149:20)
    at processPromiseRejections (node:internal/process/promises:283:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)

My Compose file:

---
version: '3.3'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    environment:
      - TZ=America/Los_Angeles
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - 3001:3001 
    restart: always

Possible Solution: I just spun up a new instance on the same server, but without any data or monitors. I added one monitor and tried maintenance mode with "Single Maintenance Window" and "Active/Inactive Manually" and then it just worked.

I'm going to try and import the other monitors into this new test instance and see if that works. I'll make an update if its still working or breaks.

EDIT: Importing the monitors to the new instance seems to have worked and I can now use the Maintenance feature again.

sassanix commented 1 month ago

WarmEthernet, I created a new instance right now as well. I added one monitor.

Then I went to schedule maintenance. Active/inactive manually and single maintenance window both worked. Then I tried the cron, and it gave me an invalid time value.

Even after trying the Recurring - Interval, the same error persisted.

Then I deleted the active/inactive and tried to add that again and then got the same error as before, too, Invalid Time Value.

WarmEthernet commented 1 month ago

Hey @sassanix,

I also just tested "Cron: and "Recurring - Interval" for a maintenance task and it worked just fine for me. Are you able to spin up a fresh new docker instance with the Timezone environment variable set within the compose file, and make sure that within the settings the "Display Timezone" and "Server Timezone" are set to match the compose file?

sassanix commented 1 month ago

Hey @sassanix,

I also just tested "Cron: and "Recurring - Interval" for a maintenance task and it worked just fine for me. Are you able to spin up a fresh new docker instance with the Timezone environment variable set within the compose file, and make sure that within the settings the "Display Timezone" and "Server Timezone" are set to match the compose file?

I have the timezone in my environment within the docker compose, but I don't have the display and server the same. The server is set to auto. I'll give that a try when I'm back on my pc and let you know.

sassanix commented 1 month ago

I tried it again, deleted the docker container, then I deleted the data folder. Started up the uptime kuma with the timezone in the environment within the docker compose, made sure the display and server are both in the same time zone, as well as the same in my docker compose.

I can't do interval or cron at all, I get the same error. But I can do single maintenance, and active, inactive manually.

sassanix commented 1 month ago

version: '3.3'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    environment:
      - TZ=America/Halifax
      - MAINTENANCE_ID=c6aa9db5-d11e-44a2-96ca-e801fedbe937
      - PUID=1000
      - PGID=1000
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - 3001:3001 
    restart: always

I tried to add more environments and I even added a maintenance id into the docker compose using uuidgen to generate an id, but still same issue.

I added the PUID and PGID , which didn't resolve the issue either.

CommanderStorm commented 1 month ago

may be releated to https://github.com/louislam/uptime-kuma/issues/4634

sassanix commented 1 month ago

may be releated to https://github.com/louislam/uptime-kuma/issues/4634

Mine won't generate the schedule, it'll just give me the error instead.

I find it interesting that 2AM to 3AM is always selected, not sure if that's done by default.

sassanix commented 1 month ago

I tried to do the same thing here https://demo.kuma.pet/start-demo and I get the same error.

I noticed that my timezone was already prefilled. The same behaviour can be replicated on the demo as the two instances that I've had on Unraid and on Debian through docker.

I tried both Chrome and Firefox, incognito, deleted the cookies and got the same error.

Here's a video of how I replicated it:

Video.webm

sassanix commented 1 month ago

I tried different timezones, I tried America/New_York and America/Toronto and both work fine, but my time zone America/Halifax gives me that error.

Is it possible that it's a bug just to my time zone?

CommanderStorm commented 1 month ago

may be releated to https://github.com/louislam/uptime-kuma/issues/4634

We will upgrade croner in #4939 If you want, you can try if that fixes this issue too. I have not had the time to debug if this is the same issue. Given that you are also using the soewhat borked recurring interval option, I think it will.

[!TIP] PRs can be test-driven via this command:

docker run --rm -it -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=buzzinJohnnyBoi:master' louislam/uptime-kuma:pr-test2

sassanix commented 1 month ago

docker run --rm -it -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=buzzinJohnnyBoi:master' louislam/uptime-kuma:pr-test2

I tried to run this, but I got an error as it couldn't pull it, I will give it another try on another machine and see if it'll run for me.

devbrsa commented 1 month ago

Is there a way to hard delete the maintenance? Seems it was soft-deleted but still causing issues.

2024-07-16T08:26:56Z [MAINTENANCE] ERROR: Error in maintenance id: 6
2024-07-16T08:26:56Z [MAINTENANCE] ERROR: Cron:
TypeError: CronPattern: invalid configuration format (''), exacly five or six space separated parts required.
    at CronPattern.parse (D:\uptime-kuma\node_modules\croner\dist\croner.min.cjs:1:8741)
    at new CronPattern (D:\uptime-kuma\node_modules\croner\dist\croner.min.cjs:1:8367)
    at new Cron (D:\uptime-kuma\node_modules\croner\dist\croner.min.cjs:1:16192)
    at Proxy.run (D:\uptime-kuma\server\model\maintenance.js:264:37)

Trace: RangeError: Invalid time value
    at DateTimeFormat.formatToParts (<anonymous>)
    at a (D:\uptime-kuma\server\modules\dayjs\plugin\timezone.js:43:22)
    at u (D:\uptime-kuma\server\modules\dayjs\plugin\timezone.js:46:21)
    at D:\uptime-kuma\server\modules\dayjs\plugin\timezone.js:98:25
    at o.tz (D:\uptime-kuma\server\modules\dayjs\plugin\timezone.js:104:14)
    at Proxy.getStatus (D:\uptime-kuma\server\model\maintenance.js:340:55)
    at async Proxy.toPublicJSON (D:\uptime-kuma\server\model\maintenance.js:53:21)
    at async UptimeKumaServer.getMaintenanceJSONList (D:\uptime-kuma\server\uptime-kuma-server.js:239:37)
    at async UptimeKumaServer.sendMaintenanceListByUserID (D:\uptime-kuma\server\uptime-kuma-server.js:226:20)
    at async UptimeKumaServer.sendMaintenanceList (D:\uptime-kuma\server\uptime-kuma-server.js:217:16)
    at process.unexpectedErrorHandler (D:\uptime-kuma\server\server.js:1905:13)
    at process.emit (node:events:513:28)
    at emit (node:internal/process/promises:149:20)
    at processPromiseRejections (node:internal/process/promises:283:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)
If you keep encountering errors, please report to https://github.com/louislam/uptime-kuma/issues

sassanix commented 1 month ago

may be releated to #4634

We will upgrade croner in #4939 If you want, you can try if that fixes this issue too. I have not had the time to debug if this is the same issue. Given that you are also using the soewhat borked recurring interval option, I think it will.

Tip

PRs can be test-driven via this command:
docker run --rm -it -p 3000:3000 -p 3001:3001 --pull always -e 'UPTIME_KUMA_GH_REPO=buzzinJohnnyBoi:master' louislam/uptime-kuma:pr-test2

I just ran this instance with your instructions, and the error remains.

Here are the logs:

  dateRange: [],
  timeRange: [
    { hours: 4, minutes: 0, seconds: 0 },
    { hours: 4, minutes: 20, seconds: 0 }
  ],
  weekdays: [],
  daysOfMonth: [],
  timezoneOption: 'America/Halifax'
}
2024-07-16T23:07:09-03:00 [MAINTENANCE] INFO: Generate cron for maintenance id: undefined
2024-07-16T23:07:09-03:00 [MAINTENANCE] DEBUG: Cron: * * * * *
2024-07-16T23:07:09-03:00 [MAINTENANCE] DEBUG: Duration: 1200
2024-07-16T23:07:09-03:00 [MAINTENANCE] DEBUG: Run maintenance id: 1
2024-07-16T23:07:09-03:00 [MAINTENANCE] ERROR: Error in maintenance id: 1
2024-07-16T23:07:09-03:00 [MAINTENANCE] ERROR: Cron: * * * * *
2024-07-16T23:07:09-03:00 [MAINTENANCE] ERROR: RangeError: Invalid time value
    at Date.toISOString (<anonymous>)
    at u.toISOString (/app/node_modules/dayjs/plugin/utc.js:1:1907)
    at Proxy.run (/app/server/model/maintenance.js:262:48)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Socket.<anonymous> (/app/server/socket-handlers/maintenance-socket-handler.js:27:13)
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Prepare Options for axios
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Axios Options: {"url":"https://google.com","method":"get","timeout":48000,"headers":{"Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"},"maxRedirects":10,"signal":{},"httpsAgent":{"_events":{},"_eventsCount":2,"defaultPort":443,"protocol":"https:","options":{"maxCachedSessions":0,"rejectUnauthorized":true,"secureOptions":4,"cookies":{"jar":{"version":"tough-cookie@4.1.4","storeType":"MemoryCookieStore","rejectPublicSuffixes":true,"enableLooseMode":false,"allowSpecialUseDomain":true,"prefixSecurity":"silent","cookies":[]}},"noDelay":true,"path":null},"requests":{},"sockets":{},"freeSockets":{},"keepAliveMsecs":1000,"keepAlive":false,"maxSockets":null,"maxFreeSockets":256,"scheduling":"lifo","maxTotalSockets":null,"totalSocketCount":0,"maxCachedSessions":0,"_sessionCache":{"map":{},"list":[]}}}
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Axios Request
2024-07-16T23:07:21-03:00 [CERT] DEBUG: Parsing Certificate Info
2024-07-16T23:07:21-03:00 [CERT] DEBUG: [0] 0B:28:0E:1B:FF:FC:C8:1B:AF:D7:4E:50:F3:EE:75:59:BB:D5:46:24
2024-07-16T23:07:21-03:00 [CERT] DEBUG: [1] 66:E4:16:12:60:B1:00:FE:E0:DE:28:7A:9A:52:93:B4:C2:22:4A:E6
2024-07-16T23:07:21-03:00 [CERT] DEBUG: [2] 08:74:54:87:E8:91:C1:9E:30:78:C1:F2:A0:7E:45:29:50:EF:36:F6
2024-07-16T23:07:21-03:00 [CERT] DEBUG: [3] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2024-07-16T23:07:21-03:00 [CERT] DEBUG: [Last] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: No need to reset sent_history
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: 72:13:7C:02:C2:D7:62:ED:B2:ED:88:F2:25:A6:05:40:40:93:DF:02:18:5E:AF:76:40:ED:25:C1:A4:23:C3:C0
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: 72:13:7C:02:C2:D7:62:ED:B2:ED:88:F2:25:A6:05:40:40:93:DF:02:18:5E:AF:76:40:ED:25:C1:A4:23:C3:C0
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Check isImportant
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: Monitor #1 'google': Successful Response: 310 ms | Interval: 60 seconds | Type: http
2024-07-16T23:07:21-03:00 [UPTIME-CALC] DEBUG: Remove old data
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Send to socket
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Store
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] prometheus.update
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] SetTimeout for next check.
2024-07-16T23:07:21-03:00 [MONITOR] DEBUG: [google] Next heartbeat in: 59667ms
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner is just started.
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: entryPage
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: nscd
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: cloudflaredTunnelToken
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: checkUpdate
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: checkBeta
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: trustProxy
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: primaryBaseURL
2024-07-16T23:07:41-03:00 [SETTINGS] DEBUG: Cache Cleaner deleted: disableAuth
2024-07-16T23:07:44-03:00 [MAINTENANCE] DEBUG: {
  title: 'nix',
  description: '',
  strategy: 'recurring-interval',
  active: 1,
  cron: '30 3 * * *',
  durationMinutes: 60,
  intervalDay: 1,
  dateRange: [],
  timeRange: [
    { hours: 4, minutes: 0, seconds: 0 },
    { hours: 4, minutes: 20, seconds: 0 }
  ],
  weekdays: [],
  daysOfMonth: [],
  timezoneOption: 'America/Halifax'
}
2024-07-16T23:07:44-03:00 [MAINTENANCE] INFO: Generate cron for maintenance id: undefined
2024-07-16T23:07:44-03:00 [MAINTENANCE] DEBUG: Cron: * * * * *
2024-07-16T23:07:44-03:00 [MAINTENANCE] DEBUG: Duration: 1200
2024-07-16T23:07:45-03:00 [MAINTENANCE] DEBUG: Run maintenance id: 2
2024-07-16T23:07:45-03:00 [MAINTENANCE] ERROR: Error in maintenance id: 2
2024-07-16T23:07:45-03:00 [MAINTENANCE] ERROR: Cron: * * * * *
2024-07-16T23:07:45-03:00 [MAINTENANCE] ERROR: RangeError: Invalid time value
    at Date.toISOString (<anonymous>)
    at u.toISOString (/app/node_modules/dayjs/plugin/utc.js:1:1907)
    at Proxy.run (/app/server/model/maintenance.js:262:48)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Socket.<anonymous> (/app/server/socket-handlers/maintenance-socket-handler.js:27:13)
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Prepare Options for axios
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Axios Options: {"url":"https://google.com","method":"get","timeout":48000,"headers":{"Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"},"maxRedirects":10,"signal":{},"httpsAgent":{"_events":{},"_eventsCount":2,"defaultPort":443,"protocol":"https:","options":{"maxCachedSessions":0,"rejectUnauthorized":true,"secureOptions":4,"cookies":{"jar":{"version":"tough-cookie@4.1.4","storeType":"MemoryCookieStore","rejectPublicSuffixes":true,"enableLooseMode":false,"allowSpecialUseDomain":true,"prefixSecurity":"silent","cookies":[]}},"noDelay":true,"path":null},"requests":{},"sockets":{},"freeSockets":{},"keepAliveMsecs":1000,"keepAlive":false,"maxSockets":null,"maxFreeSockets":256,"scheduling":"lifo","maxTotalSockets":null,"totalSocketCount":0,"maxCachedSessions":0,"_sessionCache":{"map":{},"list":[]}}}
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Axios Request
2024-07-16T23:08:21-03:00 [CERT] DEBUG: Parsing Certificate Info
2024-07-16T23:08:21-03:00 [CERT] DEBUG: [0] 0B:28:0E:1B:FF:FC:C8:1B:AF:D7:4E:50:F3:EE:75:59:BB:D5:46:24
2024-07-16T23:08:21-03:00 [CERT] DEBUG: [1] 66:E4:16:12:60:B1:00:FE:E0:DE:28:7A:9A:52:93:B4:C2:22:4A:E6
2024-07-16T23:08:21-03:00 [CERT] DEBUG: [2] 08:74:54:87:E8:91:C1:9E:30:78:C1:F2:A0:7E:45:29:50:EF:36:F6
2024-07-16T23:08:21-03:00 [CERT] DEBUG: [3] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2024-07-16T23:08:21-03:00 [CERT] DEBUG: [Last] B1:BC:96:8B:D4:F4:9D:62:2A:A8:9A:81:F2:15:01:52:A4:1D:82:9C
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: No need to reset sent_history
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: 72:13:7C:02:C2:D7:62:ED:B2:ED:88:F2:25:A6:05:40:40:93:DF:02:18:5E:AF:76:40:ED:25:C1:A4:23:C3:C0
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: 72:13:7C:02:C2:D7:62:ED:B2:ED:88:F2:25:A6:05:40:40:93:DF:02:18:5E:AF:76:40:ED:25:C1:A4:23:C3:C0
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Check isImportant
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: Monitor #1 'google': Successful Response: 295 ms | Interval: 60 seconds | Type: http
2024-07-16T23:08:21-03:00 [UPTIME-CALC] DEBUG: Remove old data
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Send to socket
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Store
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] prometheus.update
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] SetTimeout for next check.
2024-07-16T23:08:21-03:00 [MONITOR] DEBUG: [google] Next heartbeat in: 59684ms
2024-07-16T23:08:41-03:00 [SETTINGS] DEBUG: Cache Cleaner is just started.

sassanix commented 1 month ago

My workaround for this has been to use New York so far because they observe the same daylight savings patterns.

But wish it would be addressed in the future.

louislam / uptime-kuma