Incorrect billing on GPU that's only been used for a few hours. reported 410h

[Andreas_Werle_van_de]

We have the health check’s set up. But this should not activate the usage of the GPU right? its just to see f we can reach the Koyeb servers.

Here’s a picture of our usage graph to show when we actually used the system (over 7days)

It is physically not possible for us to have racked up 420 hours as billing states

gpu_nvidia_rtx_4000_sff_ada instance 419h 01m 21s

Here is the scaling settings

[I tried to upload a screenshot showing 0 as minimum and 1 on maximum for the slider but I’m a new user]

Can someone please explain to me what I’m not understanding, or help us resolve this.

As far as I understand INTERNAL health checks don’t count as traffic and should enable scale to 0?

Thank you!

– – –

Update: I’m checking the service, we have NOTHING calling it and it still says active.

– – –

These logs tell me its an INTENRAL health ping keeping the server alive
INFO: 169.254.254.254:36302 - “GET /health HTTP/1.1” 200 OK

INFO:     169.254.254.254:50772 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:37506 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:32666 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:62400 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:46360 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:53966 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:25002 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:25752 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:27732 - "GET /health HTTP/1.1" 200 OK

INFO:     169.254.254.254:48004 - "GET /health HTTP/1.1" 200 OK

This is not how it’s supposed to work

[Andreas_Werle_van_de]

Guys I’ve had a support chat open where the only response I got was that our CLI script probably missed a few variables for scale to 0.

There is nothing other than the

“SERVICE_PORT=“8000”
SERVICE_ROUTES=”/:8000"

# Health Check Configuration
HEALTH_CHECK_PORT=“8000”
HEALTH_CHECK_PATH=“/health”
HEALTH_CHECK_GRACE_PERIOD=“900”

# Scaling Configuration
MIN_SCALE=“0”
MAX_SCALE=“1”
"
But I have not been getting any response from support.

[nicolas]

Hey, sorry that you haven’t gotten new response from the support. We’re tracking your issue internally

You need to set `sleep_idle_delay` in the `targets` field of `scalings`. It controls after how many seconds of inactivity your service will go to sleep.

Health checks are not counted towards the inactivity period, only public traffic.

I’m checking with the team what’s the status on your support ticket

[Andreas_Werle_van_de]

Thanks, but this is what our config says
“targets”:[{“sleep_idle_delay”:{“value”:0,“deep_sleep_value”:3900,“light_sleep_value”:0}}]

There is no explicit flag for sleep_idle_delay in the script. T

he Koyeb CLI docs do not clearly document a --sleep-idle-delay (or similar) flag for service create / service update

Furthermore the UI shows default values as shown in the picture that makes it seem like 300 sec is applied as sleep delay:

[nicolas]

Hey, I believe that support got back to you. We applied a coupon which should cover the extra costs this induced.

Thanks, but this is what our config says
“targets”:[{“sleep_idle_delay”:{“value”:0,“deep_sleep_value”:3900,“light_sleep_value”:0}}]

Where did you see that value? In our database, there is no sleep_idle_delay target. I think that the control panel might not handle this case (which is not expected) well and thus showing default values for sleep_idle_delay.

In any case, we’re rolling out a fix to ensure sleep_idle_delay is always configured when creating a new service. Sorry for the inconvenience!

[Andreas_Werle_van_de]

I really appreciate this guys!
I am going to review the documentation and ask one of our engineers who created the file where he got a hold of that value.
Do you suggest I remove the sleep_idle_delay?

[nicolas]

Hey! You should keep sleep_idle_delay