HTTP 507 Insufficient Storage

Quick reference

What 507 means

The server understood the request and was authorized to fulfill it, but cannot complete the action because there is not enough storage space available — either on disk, in a database, in a quota system, or in an object store. The condition is temporary: once storage is freed or expanded, the same request can succeed.

507 was formally defined by RFC 4918 in the context of WebDAV (Web Distributed Authoring and Versioning), where clients can upload, copy, and move files via HTTP. A COPY or PUT that would exceed available disk space returns 507. But the code has since migrated into general API use: any server that enforces storage quotas — file hosting, object storage APIs, database write endpoints — legitimately uses 507 when a quota is reached.

RFC 4918 §11.5 states the condition may be temporary and that the server should indicate this in the response. A well-formed 507 response body includes the resource that triggered the error and the current/maximum storage values if known.

Five common causes

1. Disk full on origin server. The server's file system is at 100% capacity. Any write — including temp file creation, log rotation, or session storage — fails. This affects all uploads and any operation that writes to disk.

2. Database tablespace exhausted. PostgreSQL, MySQL, or SQL Server tablespace or data directory is full. INSERT and UPDATE operations fail. SELECT operations may continue depending on whether internal temp tables are needed.

3. Per-user storage quota exceeded. A multi-tenant application enforces per-account storage limits. The user's quota is reached and further uploads are rejected with 507 even if the server has disk space available.

4. Object storage bucket policy limit. S3 bucket policies, Azure Blob storage, or Google Cloud Storage can enforce maximum object counts or total size limits via lifecycle rules or IAM conditions. Exceeding these returns a storage-related error that the application maps to 507.

5. Temporary directory full. An application writes large temp files during processing (image conversion, video transcoding, archive extraction) and fills the temp filesystem (/tmp or a dedicated volume). Processing requests fail with 507 until temp files are cleaned.

Diagnosing storage issues

Check disk usage on Linux:

df -h
# Look for filesystems at or near 100% Use%
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   39G  0    100% /
tmpfs           7.8G  7.8G    0  100% /tmp

# Find largest directories consuming space:
du -sh /* 2>/dev/null | sort -rh | head -20

# Find and remove old log files:
find /var/log -name "*.gz" -mtime +30 -delete
find /var/log -name "*.log" -size +100M

Check inode exhaustion — a disk can show free space but have no inodes left:

df -i
# Filesystem      Inodes  IUsed   IFree IUse% Mounted on
# /dev/sda1      2621440 2621440      0  100% /

PostgreSQL database size:

-- Database sizes
SELECT pg_database.datname,
       pg_size_pretty(pg_database_size(pg_database.datname))
FROM pg_database
ORDER BY pg_database_size(pg_database.datname) DESC;

-- Table sizes in current database
SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

MySQL database size:

SELECT table_schema,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;

S3 bucket size via AWS CLI:

aws s3 ls s3://your-bucket --recursive --human-readable --summarize | tail -2
# Total Objects: 48291
# Total Size: 142.3 GiB

Recovery steps

Immediate actions when disk is full: delete old log archives (/var/log/**/*.gz), clear package manager caches (apt clean, yum clean all), remove old Docker images (docker system prune), and delete expired application temp files. These typically free gigabytes without touching application data.

For database tablespace exhaustion: add a data file to the tablespace, archive and purge old records using table partitioning + partition drops, or move the data directory to a larger volume. For PostgreSQL, VACUUM FULL and REINDEX reclaim space from deleted rows.

For per-user quota 507s: return a clear error message with current usage and limit. Include a Retry-After header if the quota resets on a schedule. Provide an upgrade path or deletion UI so users can free space themselves.

For object storage limits: review lifecycle rules and delete policies for orphaned objects, enable intelligent tiering for cold data, or request a quota increase from the storage provider.

507 vs related codes

Frequently asked questions

Should I use 507 or 413 when a file upload is too large?

Use 413 when the upload exceeds the server's configured maximum request body size, regardless of available storage. Use 507 when the upload size would be acceptable but storage is currently too full to save it. The distinction is configuration limit versus actual resource exhaustion.

Can I use 507 outside of WebDAV?

Yes. RFC 4918 defines 507 but does not restrict it to WebDAV applications. Any HTTP API that encounters a genuine storage exhaustion condition may return 507. File hosting, cloud storage, and content management APIs commonly use it.

Is 507 cacheable?

No. The storage condition is transient and state-dependent. Caching a 507 response and replaying it to future clients would be incorrect, since storage might be available by the time the next request arrives.

What should the 507 response body contain?

Best practice: return a JSON body with an error code, human-readable message, current usage, and maximum allowed. For example: {"{"}"error":"storage_quota_exceeded","used_bytes":5368709120,"quota_bytes":5368709120{"}"}. This allows clients to display meaningful messages to end users.

Related guides

HTTP 413 · HTTP 500 · HTTP 429 · HTTP 508 · Cloudflare 520

Server Errors Hub · All Guides · Home