sveltejs/kit · warning

The `status` property of `handleError` is deprecated. Use `e

Error message

The `status` property of `handleError` is deprecated. Use `error.status` for expected and framework errors, or `500` for unexpected errors.

What it means

The object passed to the `handleError` hook carries a legacy `status` property implemented as a getter that warns on access. It is deprecated because status semantics differ between expected/framework errors and unexpected errors; developers should use `error.status` or hardcode 500.

Source

Thrown at packages/kit/src/utils/error.js:57

 * @param {unknown} error
 */
export function get_status(error) {
	return error instanceof HttpError || error instanceof SvelteKitError ? error.status : 500;
}

/**
 * Adds development-only compatibility accessors for the former top-level `status` and `message`
 * properties of the `handleError` hook input.
 * @template {object} T
 * @param {T} input
 * @param {{ status: number; message: string }} fallback
 * @returns {T}
 */
export function add_deprecated_handle_error_properties(input, fallback) {
	Object.defineProperties(input, {
		status: {
			get() {
				console.warn(
					'The `status` property of `handleError` is deprecated. Use `error.status` for expected and framework errors, or `500` for unexpected errors.'
				);
				return fallback.status;
			}
		},
		message: {
			get() {
				console.warn(
					"The `message` property of `handleError` is deprecated. Use `error.message` for expected and framework errors, or 'Internal Error' for unexpected errors."
				);
				return fallback.message;
			}
		}
	});

	return input;
}

View on GitHub (pinned to 03f1687fe6)

Solutions

  1. Replace `error.status` in the hook with logic: use `error.status` for HttpError/SvelteKitError, else 500
  2. Destructure only `message` or use the second (fallback/envelope) argument's fields deliberately, accepting the deprecation temporarily
  3. Update error-reporting code to log `error.status ?? 500` from the actual error

Example fix

// before
export const handleError = ({ error, status }) => ({ message: error.message, status });
// after
export const handleError = ({ error }) => ({
  message: error.message,
  status: error instanceof HttpError || error instanceof SvelteKitError ? error.status : 500
});
Defensive patterns

Strategy: type-guard

Validate before calling

// compute status yourself instead of reading deprecated prop
function resolveStatus(error) {
  return error && typeof error === 'object' && 'status' in error && typeof error.status === 'number'
    ? error.status
    : 500;
}

Type guard

function hasOwnStatus(error) {
  return error instanceof Error && 'status' in error && typeof error.status === 'number';
}

Prevention

When it happens

Trigger: Reading `status` on the first argument inside a `handleError` hook in hooks.server.js (the getter installed by `add_deprecated_handle_error_properties` is evaluated).

Common situations: Old hook implementations migrated from earlier SvelteKit versions; error-reporting integrations that serialize the whole error object including `status`; copying hook examples from outdated tutorials.

Related errors


AI-assisted analysis of sveltejs/kit@03f1687fe6 (2026-09-02). Data as JSON: /api/errors/4306b55559b2e70a. Report an issue: GitHub.