Let me start by saying that Glitch is absolutely perfect for what I’m trying to do. My project is a time zone server, you can find the source on github at GitHub - dgnuff/TZServer: Node.js Time Zone info server.
The general idea behind the server is that you send a request of the form:
https://tzserver.glitch.me/?tzname=america/los_angeles
and the server returns a blob of JSON that contains all the data to define the time zone: both the base offset from UTC and the time and dates of the two annual changes, if they exist.
In practice, this will get accessed very infrequently. If there are more than ten requests a month, that’s heavy usage. It’s used by a couple of clocks that I built that use WiFi microcontrollers: ESP8266, they fetch the time via NTP, and then use the time zone data to convert to local time. This means that (A) they never have to be set, and (B) they correctly switch between standard time and daylight time on the correct days in March and November.
The clocks only access this once during their startup logic. Once they have the data there’s no need to access the time zone server until the next reboot, which only happens if we have a power outage. Maybe a couple of times a year, absolute tops.
Coming back to the extreme long periods of inactivity, I’m fully expecting that when the clocks do access Glitch there will be a noticeable delay before the server responds. This is totally fine, I can code around it, but this leads to the reason behind this post.
What is the absolute maximum length of time it’ll take Glitch to spin up my Node.js application to handle a request? I can set the timeout in the https:// fetch code as long as I want, but it’d be nice to get some idea of what I can expect.