how

[maiden oyster]

how to dynamically adjust cron job interval based on some metrics

[tender pond]

Hi @maiden oyster. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

---

There isn’t an explicit “dynamic interval” example in the sources, but you can combine Convex’s scheduling primitives to approximate it.

You have two main options:

---

1. Use the Crons Component (runtime‑managed crons)

With the @convex-dev/crons component you can:

• Store a cron’s configuration in Convex
• Delete and re‑register it with a new schedule from a mutation, based on metrics you compute there [Crons component].

Example pattern:

1. Register a cron with some initial interval:

// inside a mutation
const cronId = await crons.register(
  ctx,
  { kind: "interval", ms: 60_000 }, // start at 1 minute
  internal.example.logStuff,
  { message: "dynamic cron" },
  "dynamic-cron",
);

2. In another mutation, compute your metrics and adjust:

export const adjustDynamicCron = internalMutation({
  handler: async (ctx) => {
    const metrics = await computeMetrics(ctx); // your own logic

    // Decide new interval
    const newMs = metrics.loadHigh ? 10_000 : 60_000;

    // Delete old cron (by name) and re‑register with new interval
    await crons.delete(ctx, { name: "dynamic-cron" });
    await crons.register(
      ctx,
      { kind: "interval", ms: newMs },
      internal.example.logStuff,
      { message: "dynamic cron" },
      "dynamic-cron",
    );
  },
});

You can trigger adjustDynamicCron however you like (manually, from another cron, etc.). The component supports register, get, list, and delete, so this “delete + re‑register with same name” pattern is supported [Crons usage].

---

2. Fixed cron + internal rescheduling logic

Alternatively, keep a fixed cron (e.g. every minute) and implement the “dynamic interval” in your own workflow:

• Have a cron or scheduled mutation run frequently (e.g. every 10 seconds or minute) [Cron jobs].
• Inside that mutation, read your metrics and decide whether to schedule the real work now or later using ctx.scheduler.runAfter (as in the batched presence example) [Queries scale].
• You can also have a mutation that schedules itself again with runAfter to implement a variable “next run” time.

This pattern is used in the presence example, where a mutation processes a batch and, if there’s more work, schedules itself again via runAfter [Queries scale].

---

Because the docs don’t show a ready‑made “change interval in place” API, the recommended approaches from the sources are:

• For runtime‑managed crons: delete and re‑register with a new schedule using the Crons component.
• For fine‑grained control: use a fixed cron plus ctx.scheduler.runAfter and your own logic to decide when the next run should happen.

---

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@maiden oyster Kapa.ai is still learning and improving, please let me know how I did by reacting below.

[maiden oyster]

<@&1402450855881474269> ^^^^^ ?????????