Introduction

There is no single universal isRunning check that works for every timer API. The correct answer depends on which timer type you are using, because different frameworks expose timer state in different ways. In many cases, the safest design is to track the state yourself instead of assuming the timer object can always tell you.

Timer State Depends on the API

Some timer types expose an Enabled property. Others return a handle or ID that you have to manage. Others can be scheduled repeatedly without any reliable built-in running flag.

That is why the first debugging question should be: which timer class are you actually using.

Example: System.Timers.Timer

In .NET, System.Timers.Timer exposes an Enabled property.

1using System;
2using System.Timers;
3
4class Program
5{
6    static void Main()
7    {
8        var timer = new Timer(1000);
9        Console.WriteLine(timer.Enabled);
10
11        timer.Start();
12        Console.WriteLine(timer.Enabled);
13
14        timer.Stop();
15        Console.WriteLine(timer.Enabled);
16    }
17}

This is convenient, but only for timer classes that explicitly expose such state.

Example: Windows Forms Timer

A Windows Forms timer also exposes Enabled, which is often the simplest answer in UI code.

1var timer = new System.Windows.Forms.Timer();
2Console.WriteLine(timer.Enabled);
3timer.Start();
4Console.WriteLine(timer.Enabled);

If you are already in a Forms app, that property is the first thing to inspect.

Example: JavaScript Timers Need Manual Tracking

JavaScript setInterval and setTimeout do not have an object with a universal running property. You usually store the timer handle yourself.

1let intervalId = null;
2
3function start() {
4  if (intervalId !== null) return;
5  intervalId = setInterval(() => console.log("tick"), 1000);
6}
7
8function stop() {
9  if (intervalId === null) return;
10  clearInterval(intervalId);
11  intervalId = null;
12}
13
14function isRunning() {
15  return intervalId !== null;
16}

This is a good example of why manual state tracking is often the correct design.

System.Threading.Timer Is More Awkward

Some timer APIs, such as System.Threading.Timer, do not provide a direct IsRunning property. You can start, change, or dispose the timer, but checking current state is not as clean.

In those cases, wrap the timer and track the state yourself.

1using System;
2using System.Threading;
3
4class SafeTimer
5{
6    private Timer? timer;
7    public bool IsRunning { get; private set; }
8
9    public void Start()
10    {
11        timer ??= new Timer(_ => Console.WriteLine("tick"), null, Timeout.Infinite, Timeout.Infinite);
12        timer.Change(0, 1000);
13        IsRunning = true;
14    }
15
16    public void Stop()
17    {
18        timer?.Change(Timeout.Infinite, Timeout.Infinite);
19        IsRunning = false;
20    }
21}

This is often clearer than trying to infer state indirectly from callbacks.

Running Does Not Always Mean Firing Right Now

Another subtle point is that a timer may be enabled or scheduled but not currently executing its callback. A periodic timer that is waiting for the next interval is still "running" in the scheduling sense.

So define what you mean by running:

• scheduled and active
• currently executing a callback
• not stopped or disposed

Different debugging tasks need different answers.

Build for Observability

If timer state matters to your application, expose it intentionally. Add logging, counters, or explicit state fields rather than depending on framework internals.

This is especially important in concurrent systems, where the timer's lifecycle may race with callback execution.

Common Pitfalls

• Looking for a universal timer-state API that does not exist across frameworks.
• Assuming a timer is stopped just because no callback has fired recently.
• Using a timer class that does not expose state and then guessing from side effects.
• Forgetting that disposed and stopped are not always the same thing.
• Failing to track state explicitly when the application logic depends on it.

Summary

• Whether a timer is running depends on the timer API you are using.
• Some timers expose Enabled, but many do not expose a direct running flag.
• In JavaScript and several low-level timer APIs, manual state tracking is the cleanest solution.
• Define whether you mean scheduled, enabled, or actively executing.
• If timer state matters, make it explicit in your own code rather than relying on guesswork.