# Activity stuck and not processing until start-to-close timeout is hit **URL:** \ **Category:** Community Support\ **Tags:** activity, timeout\ **Created:** [June 4, 2024, 7:49am UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340 "2024-06-04T07:49:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![dnnsthnnr](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/dnnsthnnr/32/5429_2.png) [@dnnsthnnr](https://community.temporal.io/u/dnnsthnnr)\ **Post date:** [June 4, 2024, 7:49am UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/1 "2024-06-04T07:49:08Z")
Hi there, when starting a bunch of workflows in a short timeframe we notice that some activities (at random different activities) are stuck and not processing anything until they are running into their start-to-close timeout and are being retried. I was able to pinpoint a log error message by temporal-history (version 1.23.1) matching exactly the stuck activity of a given workflow stating `Fail to process task` and extras ```auto { “component”: “transfer-queue-processor”, “error”: “context deadline exceeded”, “lifecycle”: “Processing failed”, “level”: “error”, } ``` Including this stack trace: ```auto go.temporal.io/server/common/log.(*zapLogger).Error /home/runner/work/docker-builds/docker-builds/temporal/common/log/zap_logger.go:156 go.temporal.io/server/common/log.(*lazyLogger).Error /home/runner/work/docker-builds/docker-builds/temporal/common/log/lazy_logger.go:68 go.temporal.io/server/service/history/queues.(*executableImpl).HandleErr /home/runner/work/docker-builds/docker-builds/temporal/service/history/queues/executable.go:421 go.temporal.io/server/common/tasks.(*FIFOScheduler[...]).executeTask.func1 /home/runner/work/docker-builds/docker-builds/temporal/common/tasks/fifo_scheduler.go:224 go.temporal.io/server/common/backoff.ThrottleRetry.func1 /home/runner/work/docker-builds/docker-builds/temporal/common/backoff/retry.go:117 go.temporal.io/server/common/backoff.ThrottleRetryContext /home/runner/work/docker-builds/docker-builds/temporal/common/backoff/retry.go:143 go.temporal.io/server/common/backoff.ThrottleRetry /home/runner/work/docker-builds/docker-builds/temporal/common/backoff/retry.go:118 go.temporal.io/server/common/tasks.(*FIFOScheduler[...]).executeTask /home/runner/work/docker-builds/docker-builds/temporal/common/tasks/fifo_scheduler.go:233 go.temporal.io/server/common/tasks.(*FIFOScheduler[...]).processTask /home/runner/work/docker-builds/docker-builds/temporal/common/tasks/fifo_scheduler.go:211 ``` From this line: [temporal/common/tasks/fifo\_scheduler.go at v1.23.1 · temporalio/temporal · GitHub](https://github.com/temporalio/temporal/blob/v1.23.1/common/tasks/fifo_scheduler.go#L233) Can you help me understand what is failing here and how we can prevent this from affecting an activity being stuck until the start-to-close timeout is actually hit? ---
**Author:** ![tihomir](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/tihomir/32/6580_2.png) [@tihomir](https://community.temporal.io/u/tihomir)\ **Post date:** [June 4, 2024, 6:15pm UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/2 "2024-06-04T18:15:08Z")
> [@dnnsthnnr](#): > > ```auto > { > “component”: “transfer-queue-processor”, > “error”: “context deadline exceeded”, > “lifecycle”: “Processing failed”, > “level”: “error”, > } > > ``` If transient this can be ignored, if not would look at system overload / db overload. do you have service metrics? ---
**Author:** ![dnnsthnnr](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/dnnsthnnr/32/5429_2.png) [@dnnsthnnr](https://community.temporal.io/u/dnnsthnnr)\ **Post date:** [June 5, 2024, 11:48am UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/3 "2024-06-05T11:48:26Z")
Thank you for pointing me in the right direction. I noticed that our DB was under full CPU load at that time, which probably explains the `context deadline exceeded` error. ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [June 5, 2024, 11:41pm UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/4 "2024-06-05T23:41:11Z")
Long running activities must heartbeat and set HeartbeatTimeout to detect failures faster than StartToCloseTimeout. ---
**Author:** ![dnnsthnnr](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/dnnsthnnr/32/5429_2.png) [@dnnsthnnr](https://community.temporal.io/u/dnnsthnnr)\ **Post date:** [June 7, 2024, 9:07am UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/5 "2024-06-07T09:07:29Z")
That I am aware of, the thing is that the activities that are stuck are normally finished within a couple of seconds. When the stuck activities are happening I can’t see any logs or traces that they are actually running on the workers. For me, it looks like the temporal server thinks a worker is working on an activity but actually none is. Could that be the case? Are there any metrics that would support this? ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [June 7, 2024, 5:27pm UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/6 "2024-06-07T17:27:11Z")
Temporal relies on timeouts for failure detection. So, the server doesn’t know anything about the worker’s state. It waits for each activity timeout to react. ---
**Author:** ![antonioTPagoPa](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@antonioTPagoPa](https://community.temporal.io/u/antonioTPagoPa)\ **Post date:** [December 9, 2025, 5:49pm UTC](https://community.temporal.io/t/activity-stuck-and-not-processing-until-start-to-close-timeout-is-hit/12340/7 "2025-12-09T17:49:10Z")
I’m observing the same timeout error… I think it could be a network issue between DB and Temporal server occurred during a peak usage. Could it be possible to make configurable the timeout set at the following line? > This way we could just extend the time which Temporal is setting on the context used when performing the transfer activity action. Actually this lead to the need to await for the start-to-close timeout even for the very light activities (the schedule-to-start timeout would not recognize this situation). As shown in the following screenshot, even if a schedule-to-start timeout has been set, it waits for the start-to-close timeout (it was on Pending state untile the timeout) ![image](https://us1.discourse-cdn.com/flex016/uploads/temporal/original/2X/1/14eda73d87fa77b3edaeed7d29933c65f2c4f0dc.png)