# Activity Recovery: Worker behaviour in case of crash **URL:** \ **Category:** Community Support\ **Tags:** general-impl, workflow-options, dotnet-sdk\ **Created:** [May 21, 2023, 7:30am UTC](https://community.temporal.io/t/activity-recovery-worker-behaviour-in-case-of-crash/8301 "2023-05-21T07:30:47Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Liad\_Davidson](https://avatars.discourse-cdn.com/v4/letter/l/5f8ce5/32.png) [@Liad\_Davidson](https://community.temporal.io/u/Liad_Davidson)\ **Post date:** [May 21, 2023, 7:30am UTC](https://community.temporal.io/t/activity-recovery-worker-behaviour-in-case-of-crash/8301/1 "2023-05-21T07:30:48Z")
Hi All, I’ll try to explain the scenario we encountered, what I expected and what actually happened: Scenario: 1. Started 2 identical workers 2. Started workflow with a single activity that takes 30 seconds to complete (no real logic, just a simple delay). Activity set with _ScheduleToCloseTimeout_=5 minutes 3. Forcibly shut down the worker that started work on the workflow with the activity before the activity completed. Expected: Temporal engine will detect that the first one as crashed and that the workflow/activity hasn’t completed and let the second worker take over what’s left of the workflow execution. Actual: Workflow failed with a _ScheduleToCloseTimeout_ exception after the timeout expired. No attempt was made to retry the execution. Does [Temporal.io](http://Temporal.io) provide any resilience in case of a worker crashing that I’ve missed? I’m using the alpha release of the dotnet-sdk. Thanks. ---
**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:** [May 21, 2023, 11:28pm UTC](https://community.temporal.io/t/activity-recovery-worker-behaviour-in-case-of-crash/8301/2 "2023-05-21T23:28:31Z")
Temporal doesn’t directly detect worker failures. It relies on individual activity timeouts for this. The timeout for a single activity attempt is _StartToCloseTimeout_. After this timeout expiration activity is retried. You specified only _ScheduleToCloseTimeout_, which defaulted _StartToCloseTimeout_ to the same 5-minute value. So activity timed out after 5 minutes, but as it already exceeded _ScheduleToCloseTimeout_, which limits the duration of retries, a failure was reported to the workflow. If you cannot specify a shorter _StartToCloseTimeout_ as activity duration is unpredictable, you have to specify _HeartbeatTimeout_. The activity implementation should call the heartbeat at least once per heartbeat timeout. In this case, the failure will be detected after the _HeartbeatTimeout_. See the a[ctivity documentation](https://docs.temporal.io/activities#schedule-to-start-timeout) that describes all types of timeout in more details. ---
**Author:** ![taonic](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/taonic/32/5556_2.png) [@taonic](https://community.temporal.io/u/taonic)\ **Post date:** [May 21, 2023, 11:44pm UTC](https://community.temporal.io/t/activity-recovery-worker-behaviour-in-case-of-crash/8301/3 "2023-05-21T23:44:45Z")
_Late to Maxim’s answer refer to his first._ > Does [Temporal.io](http://temporal.io/) provide any resilience in case of a worker crashing that I’ve missed? Absolutely. Temporal does not detect worker crash directly. Instead, it relies on a number of timeout configurations to drive retry behaviours. See: > Note that the Temporal Server doesn’t detect Worker process failures directly. It relies on this timeout to detect that an Activity that didn’t complete on time. [https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/activity/ActivityOptions.Builder.html#setStartToCloseTimeout(java.time.Duration)](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/activity/ActivityOptions.Builder.html#setStartToCloseTimeout(java.time.Duration)) There are two activity timeout configs that tells Temporal when to perform retries: [HeartbeatTimeout](https://docs.temporal.io/activities#heartbeat-timeout) and [StartToCloseTimeout](https://docs.temporal.io/activities#start-to-close-timeout). Note, the one used in your example [ScheduleToCloseTimeout](https://docs.temporal.io/activities#schedule-to-close-timeout) tells Temporal when to **stop retry**. To make your example work, you can set the `StartToCloseTimeout` to e.g. 40 seconds. Or use `HeartbeatTimeout` if you prefer more timely retries for long running activities. ---
**Author:** ![Liad\_Davidson](https://avatars.discourse-cdn.com/v4/letter/l/5f8ce5/32.png) [@Liad\_Davidson](https://community.temporal.io/u/Liad_Davidson)\ **Post date:** [May 23, 2023, 12:32pm UTC](https://community.temporal.io/t/activity-recovery-worker-behaviour-in-case-of-crash/8301/4 "2023-05-23T12:32:45Z")
Thanks! This information along with @taonic 's addition seems to have resolve my issue.