Logs and access warnings

Middlewarr provides request logs and access warnings for different parts of a request’s journey.

View	Use it for
A proxy’s Logs tab	Requests associated with that proxy, including method, path, response status, and elapsed time
An app’s Logs tab	Reviewing traffic for the app
Tools → Warnings	Rejected requests, including failures that could not be assigned to a proxy
Container logs	Startup, template sync, server errors, and notification delivery failures

Inspect a rejected request

Open Tools → Warnings and look at the reason, app slug, source, method, and path when available. Repeated failures from the same source are grouped with a count and first/last-seen timestamps.

Reason	What to check
Unknown app slug	The client URL and the app’s current slug; an app without configured proxies can also have no loaded route
Inactive app	The app’s active state and whether it has any active proxies
Missing API key	Whether the client sends X-Api-Key or apikey
Invalid API key	Whether the key belongs to a currently active proxy for this app
Endpoint not enabled	The proxy’s effective path and method permissions

Do not rely on status code alone to identify the rejecting component. An upstream service can return its own errors after Middlewarr permits a request. Correlate the client response with Middlewarr’s logs and warnings.

Grant a missing endpoint

For an Endpoint not enabled warning, inspect the request and confirm the integration needs it. Choose Enable endpoint to review and grant it when available.

The grant flow uses the service’s OpenAPI specification to resolve concrete paths to parameterized routes. A request to /api/v3/movie/123 can become a grant for /api/v3/movie/{id}, which applies to all matching IDs.

If the path or method is absent from the specification, or the local specification cannot be read, the grant is rejected. Check Settings → OpenAPI and sync the specifications if needed. An observed request does not automatically become a supported endpoint.

You can instead open the proxy’s Endpoints tab, review the relevant method, and save the change there.

Dismiss and archive

Dismissing a warning marks it resolved; it does not change permissions or fix the client’s settings. A repeated failure creates a new unresolved warning.

Use the resolved-warning view to review archived entries. Deleting an archived warning permanently removes its stored history. Resolved warnings older than 30 days are also removed when a later access event is recorded. Fix the underlying configuration before clearing the records you need for diagnosis.

Files on disk

Proxy request logs live under /data/logs. They rotate at 5 MB, retain up to 10 backup files, expire backups after 30 days, and compress rotated files. These are file-rotation limits, not retention settings for access warnings stored in the database.

Use your container runtime’s log controls for Middlewarr’s standard output:

docker compose logs --tail=100 middlewarr

Request logs can contain operational details and query values. Review and redact any logs before sharing them. See Backups and updates for retaining the complete data directory.