[FEATURE] Support for built-in readiness, liveness, startup probes

[ka-zo]

First check

• [X] I added a very descriptive title to this issue.
• [X] I used the GitHub search to find a similar issue and didn't find it.
• [X] I searched the FastAPI documentation, with the integrated search.
• [X] I already searched in Google "How to X in FastAPI" and didn't find any information.
• [X] I already read and followed all the tutorial in the docs and didn't find an answer.
• [X] I already checked if it is not related to FastAPI but to Pydantic.
• [X] I already checked if it is not related to FastAPI but to Swagger UI.
• [X] I already checked if it is not related to FastAPI but to ReDoc.

Description

Most container platforms support some form of probing to check if the container is ready, alive or starting up. Kubernetes also supports such probes, more information is described on this link.

It is possible to manually implement such probes in a REST server written in the FastAPI web framework, however it would be nice, if FastAPI could provide such probes out of the box in order to provide an even more cloud native experience. If possible it would be nice to simply have a predefined GET path, like /ready, /alive and /startup.

Here is a good description how Spring Boot 2.3 integrates with Kubernetes probing. It looks like a nice example to follow, when implementing this feature. They basically introduce internal states, and these states influence the response for the probings mentioned above. Such states could be changed by the developer of the application written in the FastAPI web framework.

If you need further help, or you have questions, please do not hesitate to contact me.

[Divyadarshee]

Any updates on this, other links or solutions or workarounds

[Kludex]

@ka-zo What do you propose for the pub-sub system they have?

I feel like implementing this feature, either as part of FastAPI or third party package.

[ka-zo]

Hi @Kludex ,

I'm not sure what you have in mind regarding pub-sub with respect to the above mentioned probes. The way I see it, pub sub is mainly used for sending messages to certain topics, which can be received by those who subscribe to those topics. What does this have to do with readiness, liveness and startup probes?

BTW, I would be happy, if such probes would be part of FastAPI natively, as I believe such a feature would be used by most, if not all developers using FastAPI.

[ka-zo]

Hi @Divyadarshee ,

As far as I see it, there was no progress regarding this feature request, however based on the number of likes, it seems, others are also interested in it :)

[Kludex]

Hi @Kludex ,

I'm not sure what you have in mind regarding pub-sub with respect to the above mentioned probes. The way I see it, pub sub is mainly used for sending messages to certain topics, which can be received by those who subscribe to those topics. What does this have to do with readiness, liveness and startup probes?

Well...

Here is a good description how Spring Boot 2.3 integrates with Kubernetes probing. It looks like a nice example to follow, when implementing this feature.

The information about the pubsub is on this citation above. You can search for EventListener.

[Kludex]

@ka-zo Could you check my PR and let me know your thoughts, please? #2888

[Divyadarshee]

@Kludex i saw your repository fastapi-health which i tried using for /liveness or /readiness but the main blocker was it didnt return a response body as any route created by fastapi does, which brought me back to this issue. hope the feature is available soon

[nilansaha]

Indeed I feel like healthprobes and prometheus metrics should come out of the box in fastapi considering this is such a nice package and everyone uses Kubernetes these days

[NargiT]

hello, is this still a thing ? because definitely this could help to integrate faster fastapi application to k8s clusters

[Talador12]

Definitely interested in this feature

[dearkafka]

please, consider adding this feature. would help a lot!

[sravansagi]

Interested in this feature

[RRRajput]

Interested in this feature.

[alecgerona]

I believe it can be as simple as exposing a default endpoint that can be used by k8s. Can even parametrize it to depend on specific app requirements.

[tiangolo]

Thanks for the discussion everyone! ☕

Here's my rationale (more or less) to decide these things:

I consider two options:

• Teaching people how to build something directly, explaining the needed concepts, code, and teaching them how to do it themselves.
• Include some of that functionality in the library (in this one or an additional library, etc), teaching them the needed concepts, and how to use this new feature/library (instead of teaching them how to do things directly themselves).

If the effort required from users to learn the new functionality in the library is a lot less than what wold be needed to learn how to build it themselves, I would put it in the library, if not, I would rather teach them the underlying concepts and code.

At some point, they might still need to learn the underlying concepts and code anyway, and if they had to learn an abstraction before learning the actual concepts, in the end, they had to learn the double.

Also, if the new feature/library adds some noticeable improvement in some way, e.g. developer experience (autocompletion, type annotations) compared to doing things by hand, or makes things particularly easier, then I add the feature/library.

The other thing is, if I document how to add probes by hand, people that come searching for that can find it. But if it's part of the library as a feature, and more keyword arguments, everyone will end up seeing them, and maybe wondering what that's for, and having to learn it or feel they don't know a part of the tool.

I probably consider other things that I don't remember right now from the top of my head, but you get the point.

In this particular case, I don't think having this as part of the library is saving users that much effort compared to teaching them how to write the code themselves. And also "liveness" and "readiness" will be quite dependent on the application. So, adding all the needed parameters and configs would require quite some complexity on the library and complexity people would have to learn. So I would prefer to teach them how to add the endpoints themselves and what things to consider.

But I would take a PR adding docs about creating probes by hand, or otherwise, I'll probably write that at some point. 🤓 ☕

Sorry for the long delay! 🙈 I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.

[github-actions[bot]]

Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs.