HTTP 418 I'm a teapot

HTTP 418 I'm a Teapot was defined in RFC 2324 (Hyper Text Coffee Pot Control Protocol) as an April Fools' joke in 1998. When a coffee-making request is sent to a teapot, it returns 418 because it's permanently a teapot. Despite being a joke, it's become a beloved part of internet culture. Google hides an Easter egg at google.com/teapot. While not a real production status code, 418 is occasionally used as a fun response for blocked requests or as a placeholder.

Debug HTTP 418 live
Analyze real 418 behavior — headers, caching, CORS, redirects
Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/418

Example request:

curl -i "https://httpstatus.com/api/status/418"
Try in playground

Meaning

I'm a teapot (April Fools' joke from RFC 2324, HTCPCP). Any attempt to brew coffee with a teapot should result in this error. Not for serious use.

What it guarantees
  • The request was not fulfilled due to a client-side issue.
What it does NOT guarantee
  • Retries will succeed without changing request inputs.
  • The server is healthy; it may still be failing for other reasons.

When to use this status

  • Validation fails (missing fields, invalid types, invalid params).
  • A required header is missing or malformed (Content-Type, Authorization).
  • The client is not allowed to perform the operation.

When NOT to use this status (common misuses)

Using 400 for authentication/authorization failures.
Clients cannot distinguish validation vs auth; retry/login flows break.
Using 404 to mask permission issues everywhere.
Monitoring misclassifies access bugs; SEO can degrade if real pages appear missing.
Returning 4xx for server-side bugs.
Clients stop retrying; incidents are masked as client behavior.

Critical headers that matter

Content-Type
Defines error body format (JSON/text/problem+json).
Clients can’t parse structured errors; observability loses fidelity.
Cache-Control
Prevents caching transient errors unless intended.
CDNs cache failures; prolonged user-visible outages.

Tool interpretation

Browsers
Displays an error state; devtools exposes status and headers. Cache headers can accidentally cache error documents.
API clients
Classifies as failure; retry policy depends on idempotency and code class. Structured errors improve handling.
Crawlers / SEO tools
Persistent failures reduce crawl rate; soft-404 patterns cause indexing instability.
Uptime monitors
Typically alerts based on rate/threshold. Consistent classification reduces false positives.
CDNs / reverse proxies
May cache errors if misconfigured; respects Cache-Control and can serve stale on origin failure.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Error cacheability and retry guidance signals
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 418 I'm a teapot using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Identify the minimum request changes required to move from client error to success.

Technical deep dive

HTTP 418 I'm a teapot has specific technical implications for API design, caching, and client behavior. Understanding the precise semantics helps distinguish it from similar status codes and implement correct error handling. The response should include a descriptive body following a consistent error schema (like RFC 7807 Problem Details) so clients can programmatically handle the error.

Real-world examples

REST API returning 418
A well-designed API returns 418 I'm a teapot with a structured error body containing the error type, human-readable message, and machine-readable code. The client uses this to display an appropriate error message or take corrective action.
Web application encountering 418
A web application receives 418 from an API call. The frontend error handler maps the status code to a user-friendly message and either prompts the user to correct their input, retry the request, or contact support.
Monitoring and alerting for 418
An observability system tracks 418 I'm a teapot responses. Client errors (4xx) are typically logged at WARN level since they indicate client issues, not server problems. Spikes in 418 responses may indicate a broken client deployment or API contract change.

Framework behavior

Express.js (Node)
Express: res.status(418).json({ error: 'I'm a teapot', message: 'Descriptive error' }). Custom error middleware: app.use((err, req, res, next) => { if (err.status === 418) res.status(418).json(err.body); });
Django / DRF (Python)
Django REST Framework handles 418 through exception classes. Custom: raise APIException(detail='Error message', code=418). DRF's exception_handler formats consistent error responses.
Spring Boot (Java)
Spring: throw new ResponseStatusException(HttpStatus.valueOf(418), "Error message"). Or use @ControllerAdvice to handle specific exception types and return 418 with structured error bodies.
FastAPI (Python)
FastAPI: raise HTTPException(status_code=418, detail='Error message'). Custom exception handler: @app.exception_handler(CustomError) to return 418 with structured error responses.

Debugging guide

  1. Read the full response body — well-designed APIs include error details explaining why 418 was returned
  2. Check request headers (Authorization, Content-Type, Accept) — many 418 errors stem from missing or incorrect headers
  3. Compare your request against the API documentation — verify required fields, parameter types, and URL format
  4. Use curl -v or httpie to reproduce the request and see the full HTTP exchange
  5. Check server logs for additional context — the response body may be a sanitized version of a more detailed server-side error

Code snippets

Node.js
// Handle 418 I'm a teapot in Express
app.use((err, req, res, next) => {
  if (err.status === 418) {
    return res.status(418).json({
      type: 'https://api.example.com/errors/i'm-a-teapot',
      title: 'I'm a teapot',
      status: 418,
      detail: err.message
    });
  }
  next(err);
});
Python
from fastapi import HTTPException

# Raise 418 I'm a teapot
raise HTTPException(
    status_code=418,
    detail={
        'type': 'i'm_a_teapot',
        'message': 'Descriptive error for 418 I'm a teapot'
    }
)
Java (Spring)
// Spring Boot 418 I'm a teapot handling
@ExceptionHandler(CustomI'mateapotException.class)
public ResponseEntity<ErrorResponse> handleI'mateapot(
        CustomI'mateapotException ex) {
    return ResponseEntity.status(418)
        .body(new ErrorResponse("I'm a teapot", ex.getMessage()));
}
Go
// Return 418 I'm a teapot
func errorHandler(w http.ResponseWriter, message string) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(418)
	json.NewEncoder(w).Encode(map[string]any{
		"status":  418,
		"error":   "I'm a teapot",
		"message": message,
	})
}

FAQ

What is the difference between 418 I'm a teapot and similar status codes?
418 I'm a teapot has specific semantics that distinguish it from other 4xx codes. Understanding these distinctions is crucial for proper API design and client error handling.
Should my API return 418 I'm a teapot or a different status code?
Use 418 when the error precisely matches I'm a teapot's definition. If the error is more general, consider 400 Bad Request. If it's about permissions, use 401/403. Always prefer the most specific status code that accurately describes the error.
How should clients handle 418 I'm a teapot?
Clients should: (1) read the response body for error details, (2) determine if the error is retryable, (3) take corrective action if possible (fix input, refresh auth, wait and retry), (4) display an appropriate message to the user.
How does 418 I'm a teapot affect monitoring and SLA calculations?
4xx errors are generally not counted against server-side SLAs since they indicate client errors. However, sudden spikes in 418 responses may indicate server-side issues (broken deployment, configuration change) even though they manifest as client errors.

Client expectation contract

Client can assume
  • The request failed due to client-side inputs or policy.
Client must NOT assume
  • Retries without changes will succeed.
Retry behavior
Do not retry until the request is corrected (or credentials refreshed).
Monitoring classification
Client error
Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

Related status codes

417 Expectation Failed
The expectation given in the Expect request header could not be met by the server (e.g., Expect: 100-continue was rejected).
421 Misdirected Request
The request was directed at a server that is not able to produce a response.

Explore more

Related tools
Related utilities