Task Scheduler — ASP.NET Core + Angular

Introduction

This article explains how to build a robust, production-ready Task Scheduler system using ASP.NET Core for the backend and Angular for the frontend. The scheduler supports user-created tasks, recurring schedules, background processing, retries, monitoring, and notifications. Examples use Hangfire and a lightweight scheduler approach so you can choose between managed and simple in-process solutions.

The guide is written in simple Indian English and aimed at senior developers who want a practical, copy-pasteable reference with real-world best practices.

What this system does

Users create tasks with schedule rules (one-time or recurring)
Backend stores scheduled jobs and executes tasks reliably
Supports retries, exponential backoff, and failure handling
Dashboard for monitoring, pausing, and cancelling tasks
Notifications via email or SignalR when tasks complete or fail
Support for long-running and short-running jobs

High-level architecture

[Angular SPA] <--- HTTPS/JWT ---> [ASP.NET Core API]
                     |                     |
                     |                     +--> [Hangfire / Scheduler Worker]
                     |                     |
                     |                     +--> [SQL Server / Redis] (job store)
                     |
                     +--> [SignalR Hub] (optional for realtime updates)

Notes

Hangfire uses a persistent storage (SQL Server, Redis) for job state and is easy to operate.
Alternatively use Quartz.NET for advanced scheduling policies.
For cloud-native, use Azure WebJobs or AWS EventBridge + Lambda depending on needs.

Database design (basic)

Main tables (if you keep custom metadata separate from scheduler store):

Users(Id, UserName, Email, PasswordHash, Role, CreatedAt)
ScheduledTasks(Id, OwnerId, Name, Type, PayloadJson, CronExpression, NextRunAt, LastRunAt, Status, RetryCount, MaxRetries, CreatedAt, UpdatedAt)
TaskHistory(Id, TaskId, RunAt, DurationMs, Status, ResultJson, ErrorMessage)

Notes

PayloadJson stores the data required to execute the job (e.g., export parameters).
Status can be Scheduled, Running, Succeeded, Failed, Cancelled.
Keep TaskHistory for audit and SLA reporting.

If using Hangfire or Quartz, they maintain their own tables; you can still keep lightweight ScheduledTasks to show user-friendly names and metadata.

Scheduling model and recurrence

Support these scheduling types:

One-time: runAt (specific DateTime)
Cron-based recurring schedules (CRON expressions)
Simple patterns (daily at time, weekly on weekdays, monthly on day X)

Design: Accept both cron expression and a friendly schedule object. Convert friendly schedules to cron internally.

Validation: Validate cron expressions on the server and provide immediate feedback in UI.

Backend options: Hangfire vs Quartz vs Custom

Hangfire (recommended for most web apps):

Easy to integrate with ASP.NET Core
Persistent storage (SQL Server/Redis)
Dashboard out of the box
Support for retries, continuations, and background workers

Quartz.NET

More control and advanced scheduling features
Good for distributed systems and clustering

Custom in-process scheduler

Use IHostedService + BackgroundService to poll DB and execute due tasks
Simpler but less reliable for multi-instance setups unless you implement distributed locking (e.g., via SQL row lock or Redis lock)

Recommendation: use Hangfire for most needs; use Quartz when you need advanced triggers or clustering features not supported by Hangfire.

Example: Integrate Hangfire (Step-by-step)

Step 1: Add packages

dotnet add package Hangfire.Core
dotnet add package Hangfire.AspNetCore
dotnet add package Hangfire.SqlServer

Step 2: Configure Hangfire in Program.cs

var builder = WebApplication.CreateBuilder(args);

// Hangfire
builder.Services.AddHangfire(config =>
    config.UseSqlServerStorage(builder.Configuration.GetConnectionString("DefaultConnection")));
builder.Services.AddHangfireServer();

// other services
builder.Services.AddControllers();

var app = builder.Build();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

app.UseHangfireDashboard("/hangfire", new DashboardOptions { Authorization = new[] { new HangfireDashboardAuthorizationFilter() } });

app.MapControllers();
app.Run();

Security: Protect the Hangfire dashboard with role-based authorization and use HTTPS.

Step 3: Enqueue and schedule jobs from code

public class TaskSchedulerService : ITaskSchedulerService
{
    public string ScheduleOneTimeJob(Guid taskId, DateTime runAt)
    {
        return BackgroundJob.Schedule(() => ExecuteTask(taskId), runAt - DateTime.UtcNow);
    }

    public string ScheduleRecurringJob(Guid taskId, string cronExpression)
    {
        RecurringJob.AddOrUpdate(taskId.ToString(), () => ExecuteTask(taskId), cronExpression);
        return taskId.ToString();
    }

    [AutomaticRetry(Attempts = 3)]
    public Task ExecuteTask(Guid taskId)
    {
        // load task, run, persist history
        return Task.CompletedTask;
    }
}

Notes

Use [AutomaticRetry] to customize retries and delays.
For recurring jobs, ensure idempotency; the same recurring job may run multiple times if previous run didn't finish properly.

Job execution and idempotency

Idempotency is critical for scheduled tasks. Always design tasks so multiple executions produce the same effect or are safe to run multiple times.

Strategies

Use unique run identifiers and check history table before processing.
Use transactional updates with status flags: set Running with a row-version and update to Succeeded or Failed atomically.
For long-running tasks, use heartbeats and timeouts to detect stuck jobs.

Retry and backoff policies

Use exponential backoff for retries. Hangfire supports retry attributes; for custom logic implement a wrapper:

public async Task ExecuteWithRetries(Func<Task> action, int maxRetries = 3)
{
    var attempt = 0;
    while (true)
    {
        try { await action(); return; }
        catch (Exception ex) when (++attempt <= maxRetries)
        {
            var delay = TimeSpan.FromSeconds(Math.Pow(2, attempt));
            await Task.Delay(delay);
        }
    }
}

Log all failures and persist the exception details into TaskHistory for analysis.

Distributed locking and multi-instance safety

If you run multiple API instances and use a custom scheduler, ensure only one instance picks up a job at a time.

Options

Use Hangfire or Quartz (they handle locking via persistent storage).
Use Redis-based locks (RedLock) for cross-instance safety.
Use SQL sp_getapplock or update a LockedBy column using WHERE LockedBy IS NULL and check affected rows.

Example SQL optimistic lock

UPDATE ScheduledTasks SET LockedBy = @instanceId, LockTakenAt = GETUTCDATE()
WHERE Id = @taskId AND (LockedBy IS NULL OR LockTakenAt < DATEADD(MINUTE, -5, GETUTCDATE()));

If rows affected = 1, you hold the lock.

Task types and payloads

Support generic task types that the worker can execute. Example task types:

ExportReport — payload contains filters and destination (email/URL)
SendEmail — payload contains subject, recipients, templateId
SyncExternalService — payload contains endpoint and credentials
CleanupJob — payload contains retention rules

Store Type (string) and PayloadJson. Use a dispatcher in worker to route to the correct handler.

public async Task ExecuteTask(Guid taskId)
{
    var task = await _db.ScheduledTasks.FindAsync(taskId);
    var handler = _handlers.GetHandler(task.Type);
    await handler.Handle(task.PayloadJson);
}

Handlers should be registered via DI and implement an interface ITaskHandler.

API: Controllers and endpoints

Key endpoints:

POST /api/tasks — create scheduled task
GET /api/tasks — list tasks for user with filters and pagination
GET /api/tasks/{id} — get task details and history
POST /api/tasks/{id}/cancel — cancel a scheduled task
POST /api/tasks/{id}/run-now — trigger immediate run
GET /api/tasks/history — view execution history

Create Task example

[HttpPost]
public async Task<IActionResult> Create([FromBody] TaskCreateDto dto)
{
    var userId = User.GetUserId();
    var task = new ScheduledTask { /* map dto */ };
    _db.ScheduledTasks.Add(task);
    await _db.SaveChangesAsync();

    // schedule in Hangfire
    if (dto.Cron != null) _taskSchedulerService.ScheduleRecurringJob(task.Id, dto.Cron);
    else _taskSchedulerService.ScheduleOneTimeJob(task.Id, dto.RunAt.Value);

    return CreatedAtAction(nameof(Get), new { id = task.Id }, task);
}

Authorization: Only owners or admins should manage tasks. Validate payloads server-side and limit who can schedule sensitive job types.

Angular: UI and Services

Organise frontend modules:

tasks module: create, list, detail, history, run-now, cancel
shared module: date pickers, cron editor, confirmation modal
core module: auth, http interceptor, models

Cron editor and friendly UI

Use a friendly cron builder for users who do not know cron. Convert friendly rules to cron on client or server. Libraries: cron-editor (npm) or custom UI for daily/weekly/monthly options.

TaskService (Angular)

@Injectable({providedIn: 'root'})
export class TaskService {
  private base = '/api/tasks';
  constructor(private http: HttpClient) {}

  create(dto: any) { return this.http.post(this.base, dto); }
  list(query: any) { return this.http.get(this.base, { params: query }); }
  get(id: string) { return this.http.get(`${this.base}/${id}`); }
  cancel(id: string) { return this.http.post(`${this.base}/${id}/cancel`, {}); }
  runNow(id: string) { return this.http.post(`${this.base}/${id}/run-now`, {}); }
  history(id: string) { return this.http.get(`${this.base}/${id}/history`); }
}

Task list and detail

Show next run, last run, status and actions (run now, cancel, edit)
For recurring jobs show cron expression and friendly text
Show execution history with duration and result snippets

Notifications and real-time updates

Use SignalR to push task status updates to users. When a job finishes, worker broadcasts TaskUpdated event which clients subscribed to dashboard receive and refresh UI.

Worker snippet

await _hubContext.Clients.User(ownerId.ToString()).SendAsync("TaskUpdated", new { taskId = task.Id, status = task.Status });

Protect SignalR hub with authentication and ensure hub scaling (use Azure SignalR or backplane if multiple worker instances).

Monitoring and observability

Track these metrics:

Job success rate and failure rate
Average job execution time
Number of retries and longest running jobs
Queue length and worker health

Use Application Insights or Prometheus + Grafana. Also configure alerts for increased failure rate or backlog.

Testing strategy

Unit test handlers and service logic using in-memory DB or mocks
Integration tests for scheduling pipeline using Hangfire test server or local storage
E2E tests for UI flows (create task, run now, cancel)
Load test scheduling (many jobs scheduled at same time) to find bottlenecks

Security considerations

Validate and sanitize PayloadJson for dangerous content
Restrict who can schedule certain job types (e.g., SendEmail to external domains)
Use role-based authorization and fine-grained policies
Limit payload size and rate limit job creation
Use HTTPS and secure credentials for external systems used by job handlers

Scaling and deployment

Run workers separately from API servers for stable throughput
Use dedicated Hangfire workers in containerized environments
Use a persistent job store (SQL Server, Redis) shared across instances
Consider autoscaling workers based on queue length or CPU

Example: Implementing a CSV Export Job Handler

public class ExportReportHandler : ITaskHandler
{
    private readonly ApplicationDbContext _db;
    private readonly IBlobService _blob;
    private readonly IEmailService _email;

    public async Task Handle(string payloadJson)
    {
        var payload = JsonSerializer.Deserialize<ExportPayload>(payloadJson);
        var data = await BuildReportData(payload);
        using var stream = GenerateCsvStream(data);
        var url = await _blob.UploadAsync(stream, "reports/report.csv");
        await _email.SendAsync(payload.EmailTo, "Your report is ready", $"Download: {url}");
    }
}

Design handler to be idempotent: if same payload processed twice, it should not duplicate external side-effects (e.g., do not send duplicate emails). Use run identifiers persisted in TaskHistory.

Deployment checklist

Use environment secrets (key vault) for connection strings and external credentials
Run Hangfire Dashboard under secure path and role-based access
Configure health checks for API and workers
Configure logging and rotate logs
Backup DB with job history retention policy

Final best practices

Keep tasks small and focused; prefer many small jobs over one giant job
Ensure idempotency and transactional consistency
Use persistent job store and avoid in-memory schedulers in multi-instance deployments
Implement monitoring, alerting and operational runbooks
Protect scheduler UI and APIs with strong authorization

Next steps

If you want, I can:

scaffold a ready-to-run GitHub repository with API, Hangfire configuration, and Angular UI,
provide full EF Core migrations and seed data for sample tasks,
generate Angular components (create, list, detail) with unit tests,
add PNG/SVG diagrams for architecture and sequence flows.

Tell me which one you want next.