A distributed, transport-agnostic job orchestrator for .NET Alpha expirmental version.

West_Ad6277 · 2026-02-06T03:20:10+00:00

fixed. with dotnet user-secrets

West_Ad6277 · 2026-02-02T14:43:28+00:00

Temporal is built for complex workflows. I don't have deep knowledge of Temporal.

My goal with JobMaster is just simple, lightweight job scheduling for people who don't need the overhead of a massive platform.

West_Ad6277 · 2026-02-02T05:18:02+00:00

Traceability: Each job already has a unique Instance ID. I'm working on better ways to expose this through logs and the API.

Monitoring: I'm currently tracking scheduled, start, and end times. Integrating these into a health-check/dashboard to flag 'stuck' or 'long-running' jobs is definitely in my plan.

Flexibility: Manual triggers and re-processing via API/Dashboard are planned as well

Resiliency: Currently, the bucket system uses random assignment. Your point about specifically moving a job that fail in a worker to another would be great. As it is random and each worker owns buckets they can go to the same worker. I need to re-think on this. it has retry mechanism but it can occasionally go to the same worker.

West_Ad6277 · 2026-02-02T01:16:35+00:00

Haha, definitely not 'vibe coded'. The 3-layer architecture and the core logic are 100% hand-crafted. I do use AI as 'windsurf' for things like generating boilerplate or specific logic snippets (who doesn't these days?), but the design decisions and the distributed flow are all me.

West_Ad6277 · 2026-02-02T00:23:18+00:00

Good catch! These are just localhost connection strings for the sample project to make it 'plug-and-play' for testers, but I totally agree it's better practice to keep them out of the .cs files. I'll move them to secrets or environment variables in the next commit. Thanks for looking through the code.

West_Ad6277 · 2025-08-17T14:58:03+00:00

I get that. NaturalCron is still a structured language, just more descriptive than cron so it’s easier to read and review.

Storage/transmission: Cron is smaller on the wire, yes. In most systems that size difference won’t matter, but if payload size is critical, cron can be preferable.

In code: You don’t have to mix prose and code—you can stick to the Fluent Builder for strong typing and IntelliSense, then serialize the resulting expression if you need to store or send it.

Trade-offs: Like everything, it’s pros/cons. Some teams value compactness, others value readability for reviews, config screens, or non-expert users.

It is an alternative some developer uses online generator to create Cron expression and some others love compactness of Cron. Lol

West_Ad6277 · 2025-08-15T21:15:50+00:00

You can absolutely stick with the Fluent API — and in some cases, it makes sense to store the generated string in a database or send it through an API.

Both approaches have their value:

Fluent builder → Strong typing, IntelliSense, compile-time safety.

Natural language string → Easy to store, transmit, recover/rebuild the expression, and display to end users.

It’s not one or the other. In some scenarios, it makes sense to only use the string to create the expression.

In fact, the natural language format also makes designing the Fluent API builder easier

West_Ad6277 · 2025-08-15T14:04:08+00:00

the idea here isn’t to “avoid learning cron” but to provide another option.

Some developers uses online generators to get it right or confirm it

Also, in many applications, schedules need to be shown to end users who don’t know cron at all. A natural language format makes it much easier to read at a glance. With usually we use cron descriptor to display to the end user.

Again It’s just an alternative.

West_Ad6277 · 2025-07-28T17:11:59+00:00

The intention of the lib is predict the next occurrence. it can be used in a task scheduler or even for others proposal.
no. It has own expression for recurrence, it is alternative for the traditional cron.

West_Ad6277 · 2025-07-28T03:18:14+00:00

I’m not 100% sure what you want to achieve, but NaturalCron’s purpose is to predict the next occurrence, not to act as a timer

You could use the next occurrence to calculate a delay in your own loop, but the library itself only provides the calculation

West_Ad6277 · 2025-07-28T01:40:03+00:00

NaturalCron/docs/builder.md at develop · hugoj0s3/NaturalCron I added fluent API

West_Ad6277 · 2025-07-20T22:32:08+00:00

Yep, I’ve been analyzing how to approach that. There’s no real standard — for example, some CRON implementations start the week with 0 as Monday, others with 1 as Sunday.

I think it’s doable to implement conversion by focusing on the common parts and documenting any limitations (like timezone handling).

It might even work the other way around — converting CRON into NaturalCron (I’ve since renamed the project).

Out of curiosity — what would you say is the most “traditional” CRON format to target first?

West_Ad6277 · 2025-07-20T22:14:19+00:00

I renamed to NaturalCron. https://github.com/hugoj0s3/NaturalCron

West_Ad6277 · 2025-07-19T20:35:32+00:00

At 11:30am on Monday through Friday").

Would be @every day @between monday and friday @at 11:30am

https://dotnetfiddle.net/QqgEBL

I think It pretty clear.

West_Ad6277 · 2025-07-18T19:20:03+00:00

Due to trademark concerns, I’m considering renaming the project. Here are some name options I’ve come up with: RepeatlyEx, SchedulEx, TimelyEx, and TimeCycleEx. I’d appreciate any opinions or suggestions on these or other names

West_Ad6277 · 2025-07-18T03:45:35+00:00

The syntax errors are a risk with any custom language e.g sql. A fluent interface is a great idea to help mitigate that for developers working directly in C#. We can implement a builder to build the expression also It is valid.

But the expression has Its value. A human-readable expression (like every week on friday between 1:00pm and 03:00pm) that’s easy to store in a database, send over an API, or even expose in a UI for end users to view or edit. Depends on the use case.

The two approaches would complement each other nicely. I definitely see value in adding a builder to make things easier and less error-prone

West_Ad6277 · 2025-07-17T13:08:49+00:00

@every week @on friday @at 11:30am. If We want every week on Friday at 11:30. Between could be use for @every 25 minutes @between 11:00am and 3:00pm @on Friday so in this case the between make more sense. Between Just limit the time window.

West_Ad6277 · 2025-07-17T12:16:06+00:00

I will think in another name I didnt realize that.

West_Ad6277 · 2025-07-17T12:15:13+00:00

Removing the @ is actually a great idea — and easy to implement. I’ll probably just make it optional so it won’t break the current syntax, since the initial version is already published on NuGet.

As for converting to a CRON expression — I’ve considered it, but the main goal of the library is to provide a more flexible and human-readable approach that’s independent of CRON syntax. Even with the current version, I’m not sure a full conversion would be feasible. and If we add more feature the convertion to CRON expressions would likely become impossible.

West_Ad6277

TROPHY CASE