[GH-ISSUE #365] Let users specify their preferred time zone either in account settings or project settings

kerem commented

2026-02-25 23:41:52 +03:00

Owner

Originally created by @cuu508 on GitHub (Apr 29, 2020).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/365

The timezone would be used for formatting dates by default (in places where we currently use browser's timezone).

The timezone would also be selected by default when configuring cron schedules (as requested in #291)

Originally created by @cuu508 on GitHub (Apr 29, 2020). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/365 The timezone would be used for formatting dates by default (in places where we currently use browser's timezone). The timezone would also be selected by default when configuring cron schedules (as requested in #291)

kerem

2026-02-25 23:41:52 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@lukastribus commented on GitHub (Mar 8, 2021):

This should also apply to the date format in emails (via the same or a separate configuration knob).

@lukastribus commented on GitHub (Mar 8, 2021): This should also apply to the date format in emails (via the same or a separate configuration knob).

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@saschabrockel commented on GitHub (Jan 21, 2024):

Open for more than 3 years? I would love this too.

@saschabrockel commented on GitHub (Jan 21, 2024): Open for more than 3 years? I would love this too.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 21, 2024):

Open for more than 3 years?

Correct.

I would love this too.

@saschabrockel please describe the specific feature or features you are looking for.

@cuu508 commented on GitHub (Jan 21, 2024): > Open for more than 3 years? Correct. > I would love this too. @saschabrockel please describe the specific feature or features you are looking for.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@saschabrockel commented on GitHub (Jan 21, 2024):

Exactly what the issue is telling. If I create a schedule for a cronjob then it is always UTC. I forgot this in the beginning and was wondering why things didn't work as expected. I would be so nice to just have a default value / preference per account. For many cronjob it's much manual effort.

@saschabrockel commented on GitHub (Jan 21, 2024): Exactly what the issue is telling. If I create a schedule for a cronjob then it is always UTC. I forgot this in the beginning and was wondering why things didn't work as expected. I would be so nice to just have a default value / preference per account. For many cronjob it's much manual effort.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 22, 2024):

The issue mentions two use cases:

The timezone would be used for formatting dates by default (in places where we currently use browser's timezone).

I no longer think we should have a user-configurable setting for this, using browser's time zone is fine for formatting dates in "local time".

The timezone would also be selected by default when configuring cron schedules

But I do see value in this. Using browser's timezone does not work here: if I'm monitoring a server, there's a good chance my server does not use the same timezone as my browser. For the same reason we also cannot reuse the timezone setting that users can already specify in Account > Email Reports screen:

So there should probably be a separate "Default timezone for new checks" setting somewhere.

There's a question whether this should be an account-level or project-level setting. I'm leaning towards project-level, for two reasons:

Let's say you have two projects. In one project, all checks use Europe/Berlin (for example), in the other project all checks use Asia/Tokyo. If the default timezone is set at account level, we can make things convenient for one project or the other project, but not for both.
Companies often have a root account registered to something like billing@companyname.com. All projects belong to this account, and individual employees get added to project teams of specific projects. The root account is used only to manage billing and to create new projects. If the default timezone was account-level setting, users would need to sign into the root account to change it.

@cuu508 commented on GitHub (Jan 22, 2024): The issue mentions two use cases: > The timezone would be used for formatting dates by default (in places where we currently use browser's timezone). I no longer think we should have a user-configurable setting for this, using browser's time zone is fine for formatting dates in "local time". > The timezone would also be selected by default when configuring cron schedules But I do see value in this. Using browser's timezone does not work here: if I'm monitoring a server, there's a good chance my server does not use the same timezone as my browser. For the same reason we also cannot reuse the timezone setting that users can already specify in Account > Email Reports screen: ![image](https://github.com/healthchecks/healthchecks/assets/661859/5821a499-21a8-433c-ae36-ba138afb28e6) So there should probably be a separate "Default timezone for new checks" setting somewhere. There's a question whether this should be an account-level or project-level setting. I'm leaning towards project-level, for two reasons: * Let's say you have two projects. In one project, all checks use `Europe/Berlin` (for example), in the other project all checks use `Asia/Tokyo`. If the default timezone is set at account level, we can make things convenient for one project or the other project, but not for both. * Companies often have a root account registered to something like billing@companyname.com. All projects belong to this account, and individual employees get added to project teams of specific projects. The root account is used only to manage billing and to create new projects. If the default timezone was account-level setting, users would need to sign into the root account to change it.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@seidnerj commented on GitHub (May 31, 2025):

(partially) fixed by https://github.com/healthchecks/healthchecks/pull/1168

@seidnerj commented on GitHub (May 31, 2025): (partially) fixed by https://github.com/healthchecks/healthchecks/pull/1168

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 15, 2025):

In summary, I'm aware of three areas where we must be careful what timezone we use:

Timezone we use when formatting dates in times in UI (for example, when displaying logs of received pings)
Timezone we use for deciding when to send monthly, weekly reports (so they arrive between 9AM and 11AM in user's timezone)
The default timezone when creating new checks with cron/oncalendar schedule through the UI

Note – users can also create checks via API. The default timezone when crating checks via API, if not specified, is UTC. I think it should stay this way. If instead we create a user-controllable setting which changes the default timezone used in the API, I think this would just cause confusion.

Timezone we use when formatting dates in times in UI. I think the browser's timezone is fine to use here (and we already use it).
Timezone we use for deciding when to send reports. There is a timezone selector in Account Settings > Email Reports – see the screenshot in a comment above.
The default timezone when creating new checks through the UI. A while back I updated the timezone selector widget to show previously used timezones at the top of the list. If you find, say, Europe/Berlin in the list and use it once, afterwards it would show up at the top of the list and require two clicks to select. UTC is still the default. I think this is good enough. The alternative would be to add a per-project setting "default timezone for new checks if created through UI". But I feel like the confusion created by it (for some users) could outweigh the benefit (for some users).

@cuu508 commented on GitHub (Oct 15, 2025): In summary, I'm aware of three areas where we must be careful what timezone we use: * Timezone we use when formatting dates in times in UI (for example, when displaying logs of received pings) * Timezone we use for deciding when to send monthly, weekly reports (so they arrive between 9AM and 11AM in user's timezone) * The default timezone when creating new checks with cron/oncalendar schedule through the UI Note – users can also create checks via API. The default timezone when crating checks via API, if not specified, is UTC. I think it should stay this way. If instead we create a user-controllable setting which changes the default timezone used in the API, I think this would just cause confusion. * **Timezone we use when formatting dates in times in UI**. I think the browser's timezone is fine to use here (and we already use it). * **Timezone we use for deciding when to send reports**. There is a timezone selector in Account Settings > Email Reports – see the screenshot in a comment above. * **The default timezone when creating new checks through the UI**. A while back I updated the timezone selector widget to show previously used timezones at the top of the list. If you find, say, `Europe/Berlin` in the list and use it once, afterwards it would show up at the top of the list and require two clicks to select. UTC is still the default. **I think this is good enough.** The alternative would be to add a per-project setting "default timezone for new checks if created through UI". But I feel like the confusion created by it (for some users) could outweigh the benefit (for some users).

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@lukastribus commented on GitHub (Jan 7, 2026):

Unfortunately the "Status Changed to Down at" and "Status Changed to up at" Text in emails are still either TZ "+0000" or "UTC" but never the "Preferred Time Zone" from the account setting.

The email notification even mentions "Timezone: Europe/Rome" but then the Date is not actually formatted this way.

@lukastribus commented on GitHub (Jan 7, 2026): Unfortunately the "Status Changed to Down at" and "Status Changed to up at" Text in emails are still either TZ "+0000" or "UTC" but never the "Preferred Time Zone" from the account setting. The email notification even mentions "Timezone: Europe/Rome" but then the Date is not actually formatted this way. <img width="841" height="508" alt="Image" src="https://github.com/user-attachments/assets/69bd1ace-31af-433b-8470-20122331996c" /> <img width="634" height="333" alt="Image" src="https://github.com/user-attachments/assets/e68b90bc-6cec-43d6-8859-122e3bea7d97" />

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 7, 2026):

Thanks for the report. That doesn't look right, will look into it.

@cuu508 commented on GitHub (Jan 7, 2026): Thanks for the report. That doesn't look right, will look into it.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 7, 2026):

@lukastribus ah, here's a guess at what could be going on:

When we are sending an email alert, we look up the user account associated with that email address. And we use that account's time zone to format the datetimes. If the account doesn't exist, we default to UTC.

So let's say Alice has their preferred time zone as Europe/Riga, and Bob has Europe/Rome, but Charlie has no account.

Then let's say Alice in one of their projects set up email notifications to alice@example.org, bob@example.org, and charlie@example.org.

alice@example.org will receive a notification with datetimes formatted as Europe/Riga
bob@example.org will receive a notification with datetimes formatted as Europe/Rome
charlie@example.org will receive a notification with datetimes formatted as UTC

Now thinking about it, perhaps it makes more sense to default to Alice's preferred time zone, not UTC.

@cuu508 commented on GitHub (Jan 7, 2026): @lukastribus ah, here's a guess at what could be going on: When we are sending an email alert, we look up the user account associated with that email address. And we use that account's time zone to format the datetimes. If the account doesn't exist, we default to UTC. So let's say Alice has their preferred time zone as Europe/Riga, and Bob has Europe/Rome, but Charlie has no account. Then let's say Alice in one of their projects set up email notifications to alice@example.org, bob@example.org, and charlie@example.org. * alice@example.org will receive a notification with datetimes formatted as Europe/Riga * bob@example.org will receive a notification with datetimes formatted as Europe/Rome * charlie@example.org will receive a notification with datetimes formatted as UTC Now thinking about it, perhaps it makes more sense to default to Alice's preferred time zone, not UTC.

kerem commented

2026-02-25 23:41:53 +03:00

Author

Owner

@lukastribus commented on GitHub (Jan 7, 2026):

Confirmed, in my case the email integration uses totally different email addresses that are unrelated to the user account(s). There is no match, so it will default to UTC.

(One of the reasons is that some of the checks are related to the email/smtp setup. If email is broken, I may end up in a catch 22 where I don't get any emails, not even the emails related to email failure).

Interesting that sometimes dates are formatted in UTC and sometimes +0000.

Perhaps the "Default Timezone" would make more sense paired with a project as opposed to an account. But I can see how others may want different timezone for different accounts in the same project.

@lukastribus commented on GitHub (Jan 7, 2026): Confirmed, in my case the email integration uses totally different email addresses that are unrelated to the user account(s). There is no match, so it will default to UTC. (One of the reasons is that some of the checks are related to the email/smtp setup. If email is broken, I may end up in a catch 22 where I don't get any emails, not even the emails related to email failure). Interesting that sometimes dates are formatted in UTC and sometimes +0000. Perhaps the "Default Timezone" would make more sense paired with a project as opposed to an account. But I can see how others may want different timezone for different accounts in the same project.

Rows
Columns

[GH-ISSUE #365] Let users specify their preferred time zone either in account settings or project settings #281