🩺 flask-vitals
A drop-in Flask health blueprint — /healthz (liveness) + /readyz (readiness) in two lines.
Every service needs the same two endpoints — "are you alive?" and "can you serve?" — yet everyone re-writes them, slightly differently, in every app. flask-vitals is the boring, correct version you register once:
from flask_vitals import vitals
app.register_blueprint(vitals())
…and now GET /healthz and GET /readyz answer exactly the way orchestrators
(Kubernetes), load balancers, and external monitors
(Huginn, UptimeRobot, Uptime Kuma) expect.
✨ Features
- Liveness vs. readiness, done right —
/healthzsays the process is up;/readyzsays it can actually serve (its dependencies are reachable). - Injected checks — readiness probes your DB / cache / queue via callables you provide; the library never reaches into your stack.
- Honest status codes —
/readyzreturns503with a per-check breakdown when something is down, so "up but broken" is caught. - Zero config to start, fully tunable — custom paths, an optional version string, any number of named checks.
- Tiny & typed — one module, no dependency beyond Flask,
mypy --strict, 100 % tested. MIT-licensed.
📦 Install
pip install flask-vitals
# or
uv add flask-vitals
🚀 Quickstart
from flask import Flask
from sqlalchemy import text
from flask_vitals import vitals
app = Flask(__name__)
def db_ok() -> None:
db.session.execute(text("SELECT 1")) # raises → not ready
app.register_blueprint(vitals(checks={"db": db_ok}, version="1.4.2"))
| Request | Response | Code |
|---|---|---|
GET /healthz |
{"status": "ok", "version": "1.4.2"} |
200 |
GET /readyz |
{"ready": true, "checks": {"db": true}} |
200 |
GET /readyz |
{"ready": false, "checks": {"db": false}} (db unreachable) |
503 |
A check passes unless it returns False or raises — so a one-liner like
lambda: cache.ping() is a valid check.
Options
| Argument | Default | Purpose |
|---|---|---|
checks |
{} |
{name: callable} readiness probes |
version |
None |
echoed by /healthz when set |
liveness_path |
/healthz |
liveness route |
readiness_path |
/readyz |
readiness route |
name |
"vitals" |
blueprint name (change if registered twice) |
📡 Monitoring it (e.g. with Huginn)
Point an uptime monitor at each app:
- an HTTP monitor on
…/healthz— expected status200→ is it alive? - a keyword monitor on
…/readyzcontaining"ready": true→ is it serving?
That's the UptimeRobot/Uptime-Kuma experience for any Flask app, with no bespoke health code per service.
🛠️ Develop
uv sync
uv run ruff format --check .
uv run ruff check .
uv run mypy
uv run pytest
🧱 Architecture
One module, flask_vitals.blueprint, exposing vitals(...) -> flask.Blueprint.
No global state, no dependency beyond Flask; readiness checks are injected by the
host app, so the library stays decoupled from your stack and trivially testable.
🤝 Contributing
Issues and PRs are welcome! Keep it small and tested:
uv sync- Make your change with a test.
uv run ruff format . && uv run ruff check . && uv run mypy && uv run pytest- Open a PR.
📄 License
MIT © Clara Vanacker
Metadata
Release files for flask-vitals 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| flask_vitals-0.1.1.tar.gz | 5.0 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| flask_vitals-0.1.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 11.1 kB
Release files / flask_vitals-0.1.1.tar.gz
| Download URL | flask_vitals-0.1.1.tar.gz |
|---|---|
| Size | 5.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4d7bbd118d338e9aa7d91d2f7b542c2af05e0e5b4178e11fadd83f6b52244ecd
|
|
BLAKE2b-256 checksum How to use checksums |
8be9e97603c7ce3d8aa86d5cc84340e0b22a6e4ab08154d21e58131343dcca19
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 30, 2026.
Transparency logRelease files / flask_vitals-0.1.1-py3-none-any.whl
| Download URL | flask_vitals-0.1.1-py3-none-any.whl |
|---|---|
| Size | 6.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
edba25a108032237c2f62a54f2c45bbb2503f77169be648115809c652849fcba
|
|
BLAKE2b-256 checksum How to use checksums |
7cfb1922698043a8e395a4afe4f325afa05ef0e57051cf24bf7c0e789a34c2d7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 30, 2026.
Transparency log