PeriodicTimer (introduced in .NET 6) is a lightweight, async‑first timer primitive that fits naturally into modern async/await code and Hosted Services. Unlike the callback‑driven System.Threading.Timer, PeriodicTimer integrates cleanly with CancellationToken, avoids fire‑and‑forget pitfalls, and eliminates accidental overlapping execution.
If you’re building a background worker, scheduled job, or recurring task inside an IHostedService or BackgroundService, PeriodicTimer is often the simplest and safest tool for the job.
Why PeriodicTimer?
Async‑first by design
PeriodicTimer is built around await, not callbacks. Instead of wiring up a delegate that fires on a thread‑pool thread, you write a natural async loop:
This keeps your control flow linear and makes error handling, logging, and cancellation straightforward.
Cancellation‑friendly
WaitForNextTickAsync accepts a CancellationToken, which means:
- The loop exists naturally.
- No race conditions because no callbacks can fire after shutdown – there are no callbacks!
No accidental overlap
This is one of the biggest advantages. With callback‑based timers, if your work takes longer than the interval, the timer happily fires again — leading to overlapping executions, concurrency bugs, and resource contention.
With PeriodicTimer, the next iteration never starts until the previous one finishes:
- If your work takes 10 seconds and the interval is 5 seconds, the next tick simply waits.
- You get a natural “no overlap” guarantee unless you explicitly create concurrency.
This makes it ideal for tasks like: - Polling APIs
- Syncing data
- Running maintenance jobs
- Processing queues in batches
Simple lifecycle
PeriodicTimer implements IDisposable, so you can use it with using or dispose it in your worker’s shutdown path. There’s no event unsubscription, no callback races, and no hidden behavior.
Wrapping Up
PeriodicTimer fills a really important gap in the .NET ecosystem: a simple, async‑friendly, non‑overlapping timer that behaves exactly the way modern background services expect. It doesn’t try to be a full scheduling framework, and that’s precisely its strength. Instead of juggling callbacks, coordinating Change() and Dispose(), or defending your service from overlapping executions, you get a clean, linear await‑driven loop that plays perfectly with CancellationToken and the Hosted Service lifecycle.
For recurring background work that needs to run reliably and predictably — API polling, data synchronization, maintenance tasks, queue processing, and more — PeriodicTimer is often the most straightforward and least error‑prone solution. And when your requirements grow beyond simple intervals into cron expressions, distributed coordination, retries, or dashboards, that’s when tools like Quartz.NET or Hangfire become the right fit.
I hope you have a firm mental model for when to reach for PeriodicTimer, how to use it effectively, and how to keep your background services predictable, maintainable, and easy to reason about.
Below is a barebones implementation (without error handling which you must do to prevent exiting the loop)
Tenzin kabsang 