can't get workflows to run reliably using cron. anyone experiencing the same thing?

M

morpigOP•9/6/25, 9:28 AM

it's only triggering a single workflow instance and yet it's complaining about having too many reqs

M

morpigOP•9/6/25, 9:28 AM

JJames What's the expected behaviour if you try to create two workflows with the same i...

M

morpigOP•9/6/25, 9:47 AM

are you talking about cloudflare queues? afaik there's a mechanism in place to not send duplicate messages to handler/http pull until ACK timeout is hit.

Mmorpig are you talking about cloudflare queues? afaik there's a mechanism in place to n...

J

James•9/6/25, 11:22 AM

Yeah, CF queues. My understanding was it's at least once delivery so there's always a chance of duplicate deliveries from the queue to a consumer regardless of any ack timeouts.

J

James•9/6/25, 12:41 PM

I'm also facing an unrelated issue, I don't seem to be able to call a Durable Object from a Workflow, either inside a step or within the run() function. An error like this is returned and then the workflow stops in the

Errored

Errored

status.

internal error; reference = qkhe7o6ej7li8rrie5v0eks4

internal error; reference = qkhe7o6ej7li8rrie5v0eks4

Interestingly this works fine when I run locally via

wrangler dev

wrangler dev

. This is a simplified version of my workflow/DO:

import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent, DurableObject } from 'cloudflare:workers';
import { ActionEvent } from '../types/events';

export class Portal extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);

    console.log('Initialising portal Durable Object');
  }

  async test(): string {
    return "Hello!";
  }
}

export class ActionWorkflow extends WorkflowEntrypoint<Env, ActionEvent> {
  async run(params: WorkflowEvent<ActionEvent>, step: WorkflowStep) {
    const event = params.payload;
    const portalIdString = event.portal_id.toString();
    console.log('Starting workflow', event);

    const portal = this.env.PORTAL.getByName(portalIdString);
    const test = await portal.test();

    await step.do('test', async () => {
      console.log(test);
    });
  }
}

import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent, DurableObject } from 'cloudflare:workers';
import { ActionEvent } from '../types/events';

export class Portal extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);

    console.log('Initialising portal Durable Object');
  }

  async test(): string {
    return "Hello!";
  }
}

export class ActionWorkflow extends WorkflowEntrypoint<Env, ActionEvent> {
  async run(params: WorkflowEvent<ActionEvent>, step: WorkflowStep) {
    const event = params.payload;
    const portalIdString = event.portal_id.toString();
    console.log('Starting workflow', event);

    const portal = this.env.PORTAL.getByName(portalIdString);
    const test = await portal.test();

    await step.do('test', async () => {
      console.log(test);
    });
  }
}

import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent, DurableObject } from 'cloudflare:workers';
import { ActionEvent } from '../types/events';

export class Portal extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);

    console.log('Initialising portal Durable Object');
  }

  async test(): string {
    return "Hello!";
  }
}

export class ActionWorkflow extends WorkflowEntrypoint<Env, ActionEvent> {
  async run(params: WorkflowEvent<ActionEvent>, step: WorkflowStep) {
    const event = params.payload;
    const portalIdString = event.portal_id.toString();
    console.log('Starting workflow', event);

    const portal = this.env.PORTAL.getByName(portalIdString);
    const test = await portal.test();

    await step.do('test', async () => {
      console.log(test);
    });
  }
}

import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent, DurableObject } from 'cloudflare:workers';
import { ActionEvent } from '../types/events';

export class Portal extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);

    console.log('Initialising portal Durable Object');
  }

  async test(): string {
    return "Hello!";
  }
}

export class ActionWorkflow extends WorkflowEntrypoint<Env, ActionEvent> {
  async run(params: WorkflowEvent<ActionEvent>, step: WorkflowStep) {
    const event = params.payload;
    const portalIdString = event.portal_id.toString();
    console.log('Starting workflow', event);

    const portal = this.env.PORTAL.getByName(portalIdString);
    const test = await portal.test();

    await step.do('test', async () => {
      console.log(test);
    });
  }
}

Any ideas? Or is anyone from CF able to look up that error reference

JJames I'm also facing an unrelated issue, I don't seem to be able to call a Durable Ob...

A

Anes•9/6/25, 2:45 PM

Workflows only allow you to keep state that’s returned from steps. Any call to a Durable Object (or other async call) has to happen inside a step.do(), otherwise even if it works locally in wrangler dev it fails in production.

Here’s the corrected version:

const portalResponse = await step.do('get-portal-response', async () => {
  const portal = this.env.PORTAL.getByName(portalIdString);
  return await portal.test();
});

const portalResponse = await step.do('get-portal-response', async () => {
  const portal = this.env.PORTAL.getByName(portalIdString);
  return await portal.test();
});

const portalResponse = await step.do('get-portal-response', async () => {
  const portal = this.env.PORTAL.getByName(portalIdString);
  return await portal.test();
});

const portalResponse = await step.do('get-portal-response', async () => {
  const portal = this.env.PORTAL.getByName(portalIdString);
  return await portal.test();
});

Cloudflare Docs

Rules of Workflows

A Workflow contains one or more steps. Each step is a self-contained, individually retriable component of a Workflow. Steps may emit (optional) state that allows a Workflow to persist and continue from that step, even if a Workflow fails due to a network or infrastructure issue.

R

rbravo•9/6/25, 9:14 PM

Hey, Cloudflare team! I'm heavily using Cloudflare Workflows for one of the core features of my company, and I'm sometimes reaching the limits, which makes this feature unreliable. I've filled out the Limit Increase Request Form but never heard back—can someone help me? I need to increase some of our limits by 10x.

AAnes Workflows only allow you to keep state that’s returned from steps. Any call to a...

J

James•9/7/25, 7:31 AM

Thanks for the reply, that is initially how I had my workflow set up to call the DO from inside a step but it still fails like that also.

I tried your version exactly and still get an error response from the step, e.g:

internal error; reference = 4t7lk8kksul8hag46prmnndt

internal error; reference = 4t7lk8kksul8hag46prmnndt

J

James•9/7/25, 7:53 AM

Something must be messed up with the state of one of my DO instances, I tried the exact same code but with a different instance ID and it works fine now

Rrbravo Hey, Cloudflare team! I'm heavily using Cloudflare Workflows for one of the core...

M

Matt Silverlock•9/8/25, 4:16 PM

Which limits? Not all of the limits can be increased (many are real, hard limits).

Rrbravo Hey, Cloudflare team! I'm heavily using Cloudflare Workflows for one of the core...

M

Matt Silverlock•9/8/25, 4:32 PM

cc @mia for vis

Mmorpig can't get workflows to run reliably using cron. anyone experiencing the same thi...

M

morpigOP•9/8/25, 4:52 PM

workflows with cron is still unreliable for us. hope the team knows about this issue.

M

morpigOP•9/8/25, 4:54 PM

wondering if we're triggering it the wrong way

R

rbravo•9/8/25, 11:40 PM

@Matt @mia here's my use case for more context:

Let's say that I want to send a marketing campaign with messages for 10k+ users. And I'd like these messases to have a random interval between then within a fixed limit (e.g 10s to 120s).

The way I'm creating this now is that for each message I schedule a workflow run.

In the docs it's mentioned that "Concurrent Workflow instances (executions) per account" has a limit for 4500, I believe this is the main one that I need to be increased.

For workflows creation and deletion (let's say that the user has pressed a "Cancel campaign" button) I'm receiving a bunch of 429, but that probably a skilll issue on my part and an exponential backoff should fix it...

I'd appreciate any recs. Thank you!

_

_matt_•9/9/25, 5:22 PM

I have a workflow step that calls a container-based worker and it sometimes takes >4.5minutes (270 seconds). It seems the Durable Object that is managing the workflow times out and so the step fails.

If I had access to the DO I believe I could use

setWebSocketAutoResponse

setWebSocketAutoResponse

, but I don't think I can access the DO.

Is there some other approach that anyone could recommend?

BBen Hello! I’m wondering if anyone else is running into a similar issue that we’re h...

A

Adam Skjervold•9/10/25, 3:33 PM

Has anyone had issues with delayed sendEvent results?

I found this issue on SO: https://stackoverflow.com/questions/79633854/cloudflare-workflow-delay-of-up-to-45-minutes-when-calling-sendevent (seems like this was you Ben)

I'm building a concurrency manager to keep workflows under certain limits depending on the params

And here's what we do to reinvoke a waiting workflow:

const error = await stub
                .sendEvent({
                    type: "capacity-allocated",
                    payload: null
                })
                .catch((error) => {
                    console.error(
                        `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id}`,
                        error
                    )
                    return error as Error
                })

            if (!error) {
                // Success! Remove from waiting queue
                this.dequeueWaitingRun(waiting.instance_id)
                console.log(
                    `[drainWaiting] Successfully sent event and removed ${waiting.instance_id} from waiting queue`
                )
                const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const error = await stub
                .sendEvent({
                    type: "capacity-allocated",
                    payload: null
                })
                .catch((error) => {
                    console.error(
                        `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id}`,
                        error
                    )
                    return error as Error
                })

            if (!error) {
                // Success! Remove from waiting queue
                this.dequeueWaitingRun(waiting.instance_id)
                console.log(
                    `[drainWaiting] Successfully sent event and removed ${waiting.instance_id} from waiting queue`
                )
                const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const error = await stub
                .sendEvent({
                    type: "capacity-allocated",
                    payload: null
                })
                .catch((error) => {
                    console.error(
                        `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id}`,
                        error
                    )
                    return error as Error
                })

            if (!error) {
                // Success! Remove from waiting queue
                this.dequeueWaitingRun(waiting.instance_id)
                console.log(
                    `[drainWaiting] Successfully sent event and removed ${waiting.instance_id} from waiting queue`
                )
                const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const error = await stub
                .sendEvent({
                    type: "capacity-allocated",
                    payload: null
                })
                .catch((error) => {
                    console.error(
                        `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id}`,
                        error
                    )
                    return error as Error
                })

            if (!error) {
                // Success! Remove from waiting queue
                this.dequeueWaitingRun(waiting.instance_id)
                console.log(
                    `[drainWaiting] Successfully sent event and removed ${waiting.instance_id} from waiting queue`
                )
                const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

But when I call this last line:

const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

const new_status = await stub.status()
                console.log(
                    `[drainWaiting] New status for ${waiting.instance_id} after sending event: ${new_status.status}`
                )

I see that the new status is still 'waiting'

Did you manage to fix this @Ben?

I have half a mind to just:

let status = waiting
let attempts = 0

while (status === waiting) {
  await stub.sendEvent
  status = await stub.status
  attempts++
}

console.log("Finally lol")

let status = waiting
let attempts = 0

while (status === waiting) {
  await stub.sendEvent
  status = await stub.status
  attempts++
}

console.log("Finally lol")

let status = waiting
let attempts = 0

while (status === waiting) {
  await stub.sendEvent
  status = await stub.status
  attempts++
}

console.log("Finally lol")

let status = waiting
let attempts = 0

while (status === waiting) {
  await stub.sendEvent
  status = await stub.status
  attempts++
}

console.log("Finally lol")

Stack Overflow

Cloudflare Workflow: Delay of up to 45 minutes when calling `sendEv...

I'm working on an app which uses Cloudflare Workflows to operate a set of steps based on certain triggers. The workflow has a waitForEvent step, but when we use sendEvent in our route to continue the

A

Adam Skjervold•9/10/25, 7:13 PM

Wow this literally worked:

let attempts = 0
            let workflowHandled = false

            while (attempts < 5 && !workflowHandled) {
                attempts++

                // Send the event
                const error = await stub
                    .sendEvent({
                        type: "capacity-allocated",
                        payload: null
                    })
                    .catch((error) => {
                        console.error(
                            `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id} (attempt ${attempts}/5)`,
                            error
                        )
                        return error as Error
                    })

// Wait 2.5 seconds then check status
                await new Promise((resolve) => setTimeout(resolve, 2500))

                const status = await stub.status()
                console.log(
                    `[drainWaiting] Status check for ${waiting.instance_id} after attempt ${attempts}: ${status.status}`
                )

let attempts = 0
            let workflowHandled = false

            while (attempts < 5 && !workflowHandled) {
                attempts++

                // Send the event
                const error = await stub
                    .sendEvent({
                        type: "capacity-allocated",
                        payload: null
                    })
                    .catch((error) => {
                        console.error(
                            `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id} (attempt ${attempts}/5)`,
                            error
                        )
                        return error as Error
                    })

// Wait 2.5 seconds then check status
                await new Promise((resolve) => setTimeout(resolve, 2500))

                const status = await stub.status()
                console.log(
                    `[drainWaiting] Status check for ${waiting.instance_id} after attempt ${attempts}: ${status.status}`
                )

let attempts = 0
            let workflowHandled = false

            while (attempts < 5 && !workflowHandled) {
                attempts++

                // Send the event
                const error = await stub
                    .sendEvent({
                        type: "capacity-allocated",
                        payload: null
                    })
                    .catch((error) => {
                        console.error(
                            `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id} (attempt ${attempts}/5)`,
                            error
                        )
                        return error as Error
                    })

// Wait 2.5 seconds then check status
                await new Promise((resolve) => setTimeout(resolve, 2500))

                const status = await stub.status()
                console.log(
                    `[drainWaiting] Status check for ${waiting.instance_id} after attempt ${attempts}: ${status.status}`
                )

let attempts = 0
            let workflowHandled = false

            while (attempts < 5 && !workflowHandled) {
                attempts++

                // Send the event
                const error = await stub
                    .sendEvent({
                        type: "capacity-allocated",
                        payload: null
                    })
                    .catch((error) => {
                        console.error(
                            `[drainWaiting] Unable to send capacity-allocated event to ${waiting.instance_id} (attempt ${attempts}/5)`,
                            error
                        )
                        return error as Error
                    })

// Wait 2.5 seconds then check status
                await new Promise((resolve) => setTimeout(resolve, 2500))

                const status = await stub.status()
                console.log(
                    `[drainWaiting] Status check for ${waiting.instance_id} after attempt ${attempts}: ${status.status}`
                )

After ~5 seconds on attempt #2 it's good

O

Ollie•9/13/25, 11:23 AM

Is there any news on having singleton workflows / limiting a specifically workflow to concurrency of 1?

V

vijayaraagavan•9/15/25, 4:31 AM

Hey folks, I’m just getting started with Workflows and ran into something while testing locally. I noticed that

instance.terminate()

instance.terminate()

isn’t implemented in local dev. I figured restarting the server would clear everything, but even after a restart the workflow instance still seems to persist.

Does anyone know where the instance state is actually stored in local mode? And what’s the recommended way to create a new instance with the same ID if the previous one errored out and I want to retry with different input (since I can’t cancel or terminate locally)?

D

d3v1an7•9/15/25, 6:49 AM

Hey there, I have a quick question about Workflow limits

From limits docs: https://developers.cloudflare.com/workflows/reference/limits/

Concurrent Workflow instances (executions) per account: 4500
Maximum number of queued instances: 100,000

For queued instances, the description is: "the Workflow is queued, but not currently running. This can happen when you are at the concurrency limit and new instances are waiting for currently running instances to complete."

Question: Does a workflow that is currently in a "Sleep" step count as being active/concurrent? Queued? Something else?

Usage: I'd like to make a workflow that creates a user, then waits for a few days to check if the user has signed in.
This will lead to many "active" workflows that are mostly on a "sleep" step, and I can't work out from the docs if I'm going to run into limit issues or not.

Ty!

Vvijayaraagavan Hey folks, I’m just getting started with Workflows and ran into something while ...

D

d3v1an7•9/15/25, 6:54 AM

By default, running

wrangler dev

wrangler dev

will create a

.wrangler/state

.wrangler/state

directory where the command was run. You can also change this if you'd like!

Dd3v1an7 Hey there, I have a quick question about Workflow limits ✨ From limits docs: h...

A

avenceslau•9/15/25, 8:22 AM

When a workflow goes to sleep they stop counting towards concurrency limits and are counted as queued again

Vvijayaraagavan Hey folks, I’m just getting started with Workflows and ran into something while ...

O

Olga Silva•9/15/25, 10:23 AM

Hey,

terminate()

terminate()

is intended to terminate the instance, and although it is not supported yet in dev, it still wouldn't clear the workflow instance state.
Under

.wrangler/state/workflows

.wrangler/state/workflows

there will be 3 storage files (.sqlite, .sqllite-wal and .sqlite-shm) for each created workflow (the file names are not related to the workflow instance ids, so it is complicated to know which ones to delete). If you really want to run a workflow instance with the id equal to one that already ran, your best option is to delete the files under that directory and re-run the workflow instance.

OOlga Silva Hey, `terminate()` is intended to terminate the instance, and although it is not...

V

vijayaraagavan•9/15/25, 12:11 PM

Thank you!

O

orangesbracelet•9/15/25, 12:32 PM

hi folks, I had cronjob which takes more than 15 minutes so I refactored to workflow as there is no duration limit for steps. I was triggering workflow creation inside cronjob. But then I stuck at "too many subrequests". I send about 3k request to an api. In this case what should I do, did you have any problem like this ?

Oorangesbracelet hi folks, I had cronjob which takes more than 15 minutes so I refactored to work...

M

Matt Silverlock•9/15/25, 1:43 PM

Batch those requests into separate Workflow instance runs - e.g. instead of 3000 in one, fire off 3-4 workflows that each handle < 1000 requests to that API (https://developers.cloudflare.com/workflows/reference/limits/).

OOllie Is there any news on having singleton workflows / limiting a specifically workfl...

A

avenceslau•9/15/25, 2:51 PM

On our roadmap, stay tuned! :soontm:

Aavenceslau On our roadmap, stay tuned! :soontm:

O

Ollie•9/15/25, 3:02 PM

Ah amazing, I run around 2 million workflows a month, and have more to add

, but since they use external services I need to rate limit them

V

Victor•9/15/25, 6:03 PM

Found a bug in making workflows. Despite the docs saying you can't, you can make workflows with ids beyond 64 characters and outside of the regex listed https://developers.cloudflare.com/workflows/reference/limits/

J

jordanfinners•9/16/25, 6:19 AM

Hey, I wondered if you knew if it was possible to increase the memory limit of a workflow step? Please

I've requested via the form but not heard back.

My context is I'm processing data for my customers which can range from a few KB to a 400MB json blob.
At the moment I'm using streams to get this into R2 and some processing to reduce down the total size here.
However I then need to do a load of comparisons between this and another data set. I've tried not loading into memory and streaming but then just means I hit CPU limits when using streams rather than memory

Jjordanfinners Hey, I wondered if you knew if it was possible to increase the memory limit of a...

A

avenceslau•9/16/25, 10:48 AM

We currently cannot increase those limits. We are working on it though.

J

jordanfinners•9/16/25, 10:49 AM

Thank you for the info! Do you have a rough timeline, like first half of next year etc, for when any increases will be possible? Please

X

xenophyte1234•9/16/25, 4:58 PM

Hey, I got errors like instance.not_found for my workflow instance when I query

env.WORKFLOW.get(instanceId)

env.WORKFLOW.get(instanceId)

, while the instance is on the dashboard. Is there anything wrong? I also found occationly the dashboard page shows my workflow instance status is unknown but display it normally after I refreshed the page.

D

duxum•9/17/25, 6:27 AM

Greetings,
I am calling like this to start a workflow.

const instances = await env.MATCH_DAY_UPDATE.createBatch(
  batch.map((match) => ({ params: { matchId: match.id } })),
);

const instances = await env.MATCH_DAY_UPDATE.createBatch(
  batch.map((match) => ({ params: { matchId: match.id } })),
);

const instances = await env.MATCH_DAY_UPDATE.createBatch(
  batch.map((match) => ({ params: { matchId: match.id } })),
);

But the instances value is an empty array and no workflow is starting yet batch contain some elements.

Is there a problem?

Thanks,

O

oscar•9/17/25, 10:47 AM

Greetings, having the same issue as some others here, where valid Workflow IDs are visible in the UI but can't be found by my Worker.

Workflow name is: PipelineV2Runner-production
A Workflow ID this happened to is: e215050f-edb0-4132-9484-9da1e84019ea

I suspected some kind of race condition and tried a workaround where failed .get operations would be sent to a Queue and retried. This managed to recover some Workflows for a few minutes but has then been completely failing too.

O

Olriko•9/17/25, 3:19 PM

Hello,
Getting unhelpful error messages from Cloudflare Workflows.
The logs only show generic "run" errors without any actual error details or stack traces:

{ "source": { "level": "error", "message": "run" }, "dataset": "cloudflare-workers", "timestamp": "2025-09-17T14:51:22.136Z", "$workers": { "diagnosticsChannelEvents": [], "truncated": false, "event": { "rpcMethod": "run" }, "scriptName": "worker-insight-staging", "outcome": "exception", "eventType": "rpc", "entrypoint": "FetchAdInsightsWorkflow", "scriptVersion": { "id": "f85a34a5-8a00-4692-b0bc-4c80b91fe8ef" }, "executionModel": "stateless", "requestId": "PUFWDN8JVB9SKDFI", "wallTimeMs": 463, "cpuTimeMs": 3 }, "$metadata": { "id": "01K5C2H8MR4QRA6B5HE0KF1FBX", "requestId": "PUFWDN8JVB9SKDFI", "trigger": "default.run", "service": "worker-insight-staging", "level": "error", "error": "run", "message": "run", "account": "e97e3fed722428f4d726062eae9aa766", "type": "cf-worker-event", "fingerprint": "34bb94fedcdf1b63ffea70b314aa379b", "origin": "rpc", "messageTemplate": "run" }, "links": [] }

{ "source": { "level": "error", "message": "run" }, "dataset": "cloudflare-workers", "timestamp": "2025-09-17T14:51:22.136Z", "$workers": { "diagnosticsChannelEvents": [], "truncated": false, "event": { "rpcMethod": "run" }, "scriptName": "worker-insight-staging", "outcome": "exception", "eventType": "rpc", "entrypoint": "FetchAdInsightsWorkflow", "scriptVersion": { "id": "f85a34a5-8a00-4692-b0bc-4c80b91fe8ef" }, "executionModel": "stateless", "requestId": "PUFWDN8JVB9SKDFI", "wallTimeMs": 463, "cpuTimeMs": 3 }, "$metadata": { "id": "01K5C2H8MR4QRA6B5HE0KF1FBX", "requestId": "PUFWDN8JVB9SKDFI", "trigger": "default.run", "service": "worker-insight-staging", "level": "error", "error": "run", "message": "run", "account": "e97e3fed722428f4d726062eae9aa766", "type": "cf-worker-event", "fingerprint": "34bb94fedcdf1b63ffea70b314aa379b", "origin": "rpc", "messageTemplate": "run" }, "links": [] }

{ "source": { "level": "error", "message": "run" }, "dataset": "cloudflare-workers", "timestamp": "2025-09-17T14:51:22.136Z", "$workers": { "diagnosticsChannelEvents": [], "truncated": false, "event": { "rpcMethod": "run" }, "scriptName": "worker-insight-staging", "outcome": "exception", "eventType": "rpc", "entrypoint": "FetchAdInsightsWorkflow", "scriptVersion": { "id": "f85a34a5-8a00-4692-b0bc-4c80b91fe8ef" }, "executionModel": "stateless", "requestId": "PUFWDN8JVB9SKDFI", "wallTimeMs": 463, "cpuTimeMs": 3 }, "$metadata": { "id": "01K5C2H8MR4QRA6B5HE0KF1FBX", "requestId": "PUFWDN8JVB9SKDFI", "trigger": "default.run", "service": "worker-insight-staging", "level": "error", "error": "run", "message": "run", "account": "e97e3fed722428f4d726062eae9aa766", "type": "cf-worker-event", "fingerprint": "34bb94fedcdf1b63ffea70b314aa379b", "origin": "rpc", "messageTemplate": "run" }, "links": [] }

{ "source": { "level": "error", "message": "run" }, "dataset": "cloudflare-workers", "timestamp": "2025-09-17T14:51:22.136Z", "$workers": { "diagnosticsChannelEvents": [], "truncated": false, "event": { "rpcMethod": "run" }, "scriptName": "worker-insight-staging", "outcome": "exception", "eventType": "rpc", "entrypoint": "FetchAdInsightsWorkflow", "scriptVersion": { "id": "f85a34a5-8a00-4692-b0bc-4c80b91fe8ef" }, "executionModel": "stateless", "requestId": "PUFWDN8JVB9SKDFI", "wallTimeMs": 463, "cpuTimeMs": 3 }, "$metadata": { "id": "01K5C2H8MR4QRA6B5HE0KF1FBX", "requestId": "PUFWDN8JVB9SKDFI", "trigger": "default.run", "service": "worker-insight-staging", "level": "error", "error": "run", "message": "run", "account": "e97e3fed722428f4d726062eae9aa766", "type": "cf-worker-event", "fingerprint": "34bb94fedcdf1b63ffea70b314aa379b", "origin": "rpc", "messageTemplate": "run" }, "links": [] }

This makes debugging impossible. Is there a way to get actual error messages/stack traces from Workflows? Or is this a known logging issue?

It's a log from the worker. from the workflow page, there is no errors.

OOlriko Hello, Getting unhelpful error messages from Cloudflare Workflows. The logs only...

S

Seekerdasbatatas•9/17/25, 3:37 PM

This is an unfortunate side effect of how we guarantee durable execution, and we are trying to improve the logging pipeline so that they are not noisy for y'all

:soontm: - my recommendation for a workaround is to filter the errors from logs that don't contain error messages or stacks

SSeekerdasbatatas This is an unfortunate side effect of how we guarantee durable execution, and we...

O

Olriko•9/17/25, 4:17 PM

oh ok. so this log is not an error.
It should be awesome if logs can be displayed into the step or instance view :MeowHeartCloudflare:

F

flof.fly•9/17/25, 6:34 PM

Can i use introspectWorkflow testing inside a runInDurableObject context?

If not, what is the right way to run e2e testing locally for workers that trigger workflows that have steps with DurableObject communications?

Fflof.fly Can i use introspectWorkflow testing inside a runInDurableObject context? If no...

S

Seekerdasbatatas•9/17/25, 6:46 PM

introspectWorkflow

introspectWorkflow

should be done at the start of the test (you can think of doing

introspectWorkflow

introspectWorkflow

where you mock other APIs and so on) - intercepted workflows with DOs should just work (if you want to mock/intercept the calls between the two, let me know)

F

flof.fly•9/18/25, 7:55 PM

Why workflows have such a big wall time? what could the reason be? Is this walletime expected?
Is it related to retries?

in my workflow i have one step that is expected to fail and go errored status, maybe that's the issue there?

Here's my workflow step configs:

const defaultConfig: WorkflowStepConfig = {
    retries: {
        limit: 0,
        delay: 0,
        backoff: 'constant',
    },
    timeout: '3 minutes',
}

const defaultConfig: WorkflowStepConfig = {
    retries: {
        limit: 0,
        delay: 0,
        backoff: 'constant',
    },
    timeout: '3 minutes',
}

const defaultConfig: WorkflowStepConfig = {
    retries: {
        limit: 0,
        delay: 0,
        backoff: 'constant',
    },
    timeout: '3 minutes',
}

const defaultConfig: WorkflowStepConfig = {
    retries: {
        limit: 0,
        delay: 0,
        backoff: 'constant',
    },
    timeout: '3 minutes',
}

T

TheJudas•9/18/25, 7:57 PM

Thinking of doing some video processing using workflows is it possible to run ffmpeg there?

TTheJudas Thinking of doing some video processing using workflows is it possible to run ff...

F

full_moon_flowers•9/18/25, 9:18 PM

I don't think Workflows (Workers) supports ffmpeg natively, but IIUC you could run ffmpeg from a Container as part of a workflow

TTheJudas Thinking of doing some video processing using workflows is it possible to run ff...

S

Shivek•9/19/25, 6:06 PM

Container, or just call a 3rd party server running ffmpeg.

I

Isak•9/20/25, 1:31 PM

Can you actually see the console.logs anywhere?

J

jordanfinners•9/20/25, 9:53 PM

I'm using wait for event in a for loop to trigger nested workflow. I see the error where the parent hasn't waited for the event on longer running workflows. Is it because I'm doing this outside of a step?

M

Murder Chicken•9/21/25, 2:22 PM

When workflows are triggered via cron vs. manually triggering them from the dashboard, is there any context difference? All of a sudden, I'm seeing workflows failing they are on steps that proxy requests through another worker but if I manually trigger the workflow, it completes just fine. Trying to understand what could be different between a cron triggered workflow and one triggered through the dashboard.

M

Murder Chicken•9/21/25, 4:43 PM

Okay, looks like I understand what's going on, when you trigger the workflow it seems to initiate the worker near your geographic location. When done through

cron

cron

it seems to do it from other geographic locations. I have a security rule to block all traffic to the worker that's not from the United States and it seems that, as of recently, my cron-scheduled workflows are being instantiated outside of the United States in Poland or Singapore which is causing them to be blocked by the security rules.

Is there a way to force location of execution of workflows or whitelist / exempt same account workers from security rules?

can't get workflows to run reliably using cron. anyone experiencing the same thing?

Similar Threads