Health check endpoints in FastAPI - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a health check endpoint in a web application?

A health check endpoint is a simple URL in a web app that returns a status showing if the app is running well. It helps monitoring tools know if the app is healthy.

beginner

How do you create a basic health check endpoint in FastAPI?

You create a route with @app.get('/health') that returns a simple JSON like {'status': 'ok'}. This shows the app is running.

intermediate

Why should health check endpoints be lightweight and fast?

Because they are called often by monitoring systems. If they take too long or use many resources, they can slow down the app or give wrong health info.

beginner

What HTTP status code is commonly returned by a healthy health check endpoint?

HTTP 200 OK is returned to show the app is healthy and working as expected.

intermediate

How can you extend a health check endpoint to check database connectivity in FastAPI?

Inside the endpoint function, try a simple database query or connection test. If it works, return status ok; if it fails, return an error status and message.

What is the main purpose of a health check endpoint?

A To serve the main webpage

B To handle user login

C To update the database

D To show if the app is running properly

Health check endpoints are designed to report the app's running status to monitoring tools.

Which HTTP method is usually used for health check endpoints in FastAPI?

A PUT

B POST

C GET

D DELETE

GET is used because health checks only retrieve status information without changing data.

What should a simple health check endpoint return to indicate success?

A HTTP 404 not found

B HTTP 200 OK with status 'ok'

C HTTP 500 error

D HTTP 403 forbidden

HTTP 200 OK with a status message like 'ok' signals the app is healthy.

Why avoid heavy operations in health check endpoints?

A They slow down the app and can cause false health reports

B They improve app security

C They help with user authentication

D They increase database size

Heavy operations can delay responses and mislead monitoring systems about app health.

How can you test database connectivity in a FastAPI health check?

A Run a simple query and catch errors

B Restart the database server

C Delete all database records

D Ignore database status

Running a simple query helps confirm the database is reachable and working.

Explain how to create a basic health check endpoint in FastAPI and why it is useful.

Think about a simple URL that tells if your app is alive.

Describe how you would extend a health check endpoint to verify database connectivity.

Imagine checking if your app can talk to its database before saying it is healthy.

Practice

1. What is the main purpose of a health check endpoint in a FastAPI application?

easy

A. To serve static files like images

B. To handle user authentication

C. To confirm the app is running and responsive

D. To perform database migrations

Solution

1. Step 1: Understand the role of health check endpoints

   Health check endpoints are simple URLs that tell if the app is alive and working properly.

2. Step 2: Identify the correct purpose

   They do not handle authentication, serve files, or migrate databases but confirm app responsiveness.

3. Final Answer:

   To confirm the app is running and responsive -> Option C

4. Quick Check:

   Health check = Confirm app alive [OK]

Hint: Health check endpoints confirm app is alive and responsive [OK]

Common Mistakes:

• Confusing health check with authentication endpoints
• Thinking health check serves files
• Assuming health check runs database tasks

2. Which of the following is the correct way to define a simple health check endpoint in FastAPI?

easy

A. @app.get('/health')
def health():
return {'status': 'ok'}

B. app.route('/health', method='GET')(def health(): return 'ok')

C. app.get('/health')(def health(): return {'status': 'ok'})

D. def health():
return {'status': 'ok'}
app.get('/health', health)

Solution

1. Step 1: Recall FastAPI syntax for endpoints

   FastAPI uses decorators like @app.get('/path') above the function to define GET endpoints.

2. Step 2: Check each option's syntax

   @app.get('/health') def health(): return {'status': 'ok'} correctly uses @app.get decorator and defines a function returning JSON. Others have syntax errors or wrong decorator usage.

3. Final Answer:

   @app.get('/health')\ndef health():\n return {'status': 'ok'} -> Option A

4. Quick Check:

   Use @app.get decorator for GET endpoints [OK]

Hint: Use @app.get decorator above function for GET endpoints [OK]

Common Mistakes:

• Using app.get() as a function call instead of decorator
• Wrong decorator syntax or missing @
• Returning string instead of JSON/dict

3. Given this FastAPI health check endpoint code, what will be the JSON response when accessed?

@app.get('/health')
def health():
    return {'status': 'healthy', 'uptime': 12345}

medium

A. 500 Internal Server Error

B. {"status": "ok"}

C. 404 Not Found

D. {"status": "healthy", "uptime": 12345}

Solution

1. Step 1: Analyze the return value of the endpoint

   The function returns a dictionary with keys 'status' and 'uptime' and their values.

2. Step 2: Understand FastAPI response conversion

   FastAPI converts dict returns to JSON automatically, so the response will be JSON with those keys and values.

3. Final Answer:

   {"status": "healthy", "uptime": 12345} -> Option D

4. Quick Check:

   Dict return becomes JSON response [OK]

Hint: Returned dict becomes JSON response automatically [OK]

Common Mistakes:

• Expecting string instead of JSON
• Confusing status code with response body
• Assuming error without code issues

4. What is wrong with this FastAPI health check endpoint code?

from fastapi import FastAPI
app = FastAPI()

@app.get('/health')
def health():
    return status: 'ok'

medium

A. Missing @app.post decorator

B. Syntax error in return statement

C. Function name must be 'health_check'

D. FastAPI app instance not created

Solution

1. Step 1: Inspect the return statement syntax

   The return line uses 'return status: 'ok'' which is invalid Python syntax; it should be a dictionary like {'status': 'ok'}.

2. Step 2: Check other parts for correctness

   The decorator @app.get is correct, function name can be anything, and app instance is created properly.

3. Final Answer:

   Syntax error in return statement -> Option B

4. Quick Check:

   Return dict with braces, not 'key: value' alone [OK]

Hint: Return a dict with braces, not 'key: value' alone [OK]

Common Mistakes:

• Writing return without braces for dict
• Using wrong decorator for GET endpoint
• Assuming function name is fixed

5. You want to create a health check endpoint in FastAPI that returns HTTP 200 with JSON {'status': 'ok'} if the app is healthy, but HTTP 503 with {'status': 'unhealthy'} if a database connection fails. Which approach correctly implements this?

hard

A. Use try-except inside the endpoint to check DB, return JSON with status code accordingly

B. Always return {'status': 'ok'} and rely on external monitoring for DB status

C. Create two endpoints: one for app status and one for DB status, no status codes

D. Raise an exception if DB fails, FastAPI returns 500 automatically

Solution

1. Step 1: Understand the requirement for conditional response

   The endpoint must check DB health and respond with different JSON and HTTP status codes based on that.

2. Step 2: Evaluate options for handling DB check and response

   Use try-except inside the endpoint to check DB, return JSON with status code accordingly uses try-except to check DB and returns JSON with correct status codes, matching the requirement. Others either ignore DB status or do not set proper codes.

3. Final Answer:

   Use try-except inside the endpoint to check DB, return JSON with status code accordingly -> Option A

4. Quick Check:

   Use try-except and return JSON with status codes [OK]

Hint: Use try-except and return JSON with proper HTTP status codes [OK]

Common Mistakes:

• Ignoring database health in the endpoint
• Not setting HTTP status codes explicitly
• Relying on default 500 instead of 503 for service unavailable