Skip to main content

🩺 flask-vitals

A drop-in Flask health blueprint — /healthz (liveness) + /readyz (readiness) in two lines.

PyPI CI License: MIT Python 3.14+ Flask Ruff Checked with mypy PRs welcome


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 — /healthz says the process is up; /readyz says 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 — /readyz returns 503 with 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 status 200 → is it alive?
  • a keyword monitor on …/readyz containing "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:

  1. uv sync
  2. Make your change with a test.
  3. uv run ruff format . && uv run ruff check . && uv run mypy && uv run pytest
  4. 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)

Source distribution for flask-vitals 0.1.1
File Size Uploaded
flask_vitals-0.1.1.tar.gz 5.0 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for flask-vitals 0.1.1
File Interpreter ABI Platform
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 log

Release 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

Release history Release notifications | RSS feed

This release

0.1.1 This release

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page