You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
Add a startInterval parameter to the container health check. This was added to the Docker Engine in v25 (moby/moby#40894) so it now needs to be exposed by ECS.
Which service(s) is this request for?
ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
In my scenario I have a slow starting application. We don't want it's health to be evaluated for the first 120 seconds (to give it time to start and settle), but after that we want it's health to be evaluated every 30 seconds. Today if you set the startPeriod to 120 seconds and the interval to 30 seconds, three health checks run before the start period has finished. If all those health checks fail, then it is not a problem, the container will stay in an UNKNOWN state. However if one of those health checks passes, the container will get marked as HEALTHY due to:
If a health check succeeds within the startPeriod, then the container is considered healthy and any subsequent failures count toward the maximum number of retries.
Once a container gets marked as HEALTHY things happen in ECS (such as old tasks are stopped), therefore we have to write logic so that a health check must fail within the first 120 seconds of the container starting. The startInterval will allow us to remove this custom logic, have no health checks run during the startPeriod, and then after that startPeriod our frequent health checks.
Are you currently working around this issue?
We have to write logic so that a health check has to fail within the first 120 seconds of the application starting.
Additional context
Anything else we should know?
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
The text was updated successfully, but these errors were encountered:
Community Note
Tell us about your request
Add a
startInterval
parameter to the container health check. This was added to the Docker Engine in v25 (moby/moby#40894) so it now needs to be exposed by ECS.Which service(s) is this request for?
ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
In my scenario I have a slow starting application. We don't want it's health to be evaluated for the first 120 seconds (to give it time to start and settle), but after that we want it's health to be evaluated every 30 seconds. Today if you set the
startPeriod
to 120 seconds and theinterval
to 30 seconds, three health checks run before the start period has finished. If all those health checks fail, then it is not a problem, the container will stay in anUNKNOWN
state. However if one of those health checks passes, the container will get marked asHEALTHY
due to:https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HealthCheck.html
Once a container gets marked as
HEALTHY
things happen in ECS (such as old tasks are stopped), therefore we have to write logic so that a health check must fail within the first 120 seconds of the container starting. ThestartInterval
will allow us to remove this custom logic, have no health checks run during thestartPeriod
, and then after thatstartPeriod
our frequent health checks.Are you currently working around this issue?
We have to write logic so that a health check has to fail within the first 120 seconds of the application starting.
Additional context
Anything else we should know?
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
The text was updated successfully, but these errors were encountered: