In addition to Dave’s advice, you should also consider if it is possible for the action code of the timer to take longer to process than your timer period. For example, if the timer must perform any calls to the internet, you can easily have an instance take longer than normal.
In general, if it is possible for the action code to take longer than the timer period, you need to consider how you want it to behave. For example, you may want to keep a boolean flag and just silently skip a period when a previous period is still running. Or you may need the new period to cancel the previous period and start a new process. Or maybe your action code is safe to have running twice.
There is no single answer other than “it depends”.
If you mean to trigger something with the timer, like when you want to manipulate the UI from within a thread, you can go as low as 0 for a one-shot timer, so it will fire immediately once the event loop allows it.
For multiple mode timers, the minimum should be the time it takes to process the timer action event code. No need to worry if your period should be below it: Timers always run on the main thread, so following timer events would wait until the former has finished. They are not running concurrently. But they could queue up in this case.
EDIT: Sorry for the double information. Douglas sent his answer a few seconds before I hit “Save”
Coming at it from a slightly different perspective, if your timer is triggering something that the user sees (or hears) in the UI, then the overriding consideration is often "How frequently does this need to be updated so that the visual impact looks “smooth” or “continuous” or “responsive”. If you’re firing faster than that you might be taking time away from other processes unnecessarily, and if you fire more slowly your app might seem to “lag” or “flicker”. Thresholds of perception vary depending on whether the output is audio or visual, and also on context and repetition. 25 - 50ms is usually imperceptible in one-time visual events, 100ms is usually acceptable, and in many cases you can get away with 250ms.