Points Troubleshooting

When a create or resize is rejected for points reasons, the platform tells you exactly which limit you hit. This page lists each rejection you can see across the marketplace — apps, databases, object storage, and auth — quotes the real message, explains what it means, and gives the fix.

For the model behind all of this — budgets, reserve and refund, max tiers — read Points & Plans first. For the per-service formulas, see Pricing by Service.

”would exceed your plan’s points budget”

A create or resize would push your project’s reserved footprint past your plan’s points budget. The leading verb changes with the action, but the tail is always the same:

You’ll see the same message shape for every pointed resource — creating this app…, creating this bucket…, creating this auth app…, and for resizes this change would…, this app size would…, resizing this bucket would….

What it means. Points are an allowance on your maximum concurrent footprint, and this one request wouldn’t fit under your remaining budget. The request is rejected up front — nothing is created and nothing already running is touched. Your existing apps, databases, storage, and auth keep running exactly as before.

The fix — three paths (covered in full under When you run out of points):

1. Upgrade your plan. A larger plan means a larger budget, effective immediately.
2. Free up points. Delete a resource you no longer need, or downsize one that’s larger than it has to be. Deleting refunds the full cost, and a downsize refunds the difference — the points come back right away.
3. Switch to pay-as-you-go. Graduating to PAYG lifts the points budget entirely; you’re metered on what you actually use instead of holding a fixed allowance.

Freeing points and upgrading both take effect the moment they complete, so a rejected request usually succeeds on the very next try once you’ve made room.

”platform capacity is temporarily exhausted”

What it means. This one is not about your plan. Ghayma is temporarily at capacity across the platform, so the create was held back regardless of how many points you have left — you’d see it even with your whole budget free. It is not your fault and it is not a prompt to upgrade.

The fix. Wait a little while and try again. Nothing on your plan needs to change. If the rejection persists, contact support so we can check platform capacity — don’t upgrade your plan expecting it to help, because your plan isn’t the constraint here.

A database disk resize has a storage form of this: 503 with code: storage_capacity means the platform does not have the storage for a disk of that size right now. Try a smaller size, or try again later.

”tier exceeds the plan’s maximum”

The full message names the tiers involved, for example tier "m" (Medium) exceeds plan max tier "s" (Small).

What it means. This is a guardrail, not a budget problem. Each plan sets a maximum app tier and a maximum database tier. A tier above that cap is unavailable no matter how many points you have left — the cap protects the platform and is separate from your points budget.

The fix. Upgrade to a plan whose maximum tier covers the tier you want, then retry.

Disk too small for the data

A database disk can shrink only if what the volume holds fits in 75 % of the new size. A smaller request is refused with 409 and code: disk_too_small, and nothing changes:

What it means. The volume holds more than your data: the engine’s own files, such as PostgreSQL’s WAL or MongoDB’s journal, count too. The quarter left free is room for the database to keep writing after the move.

The fix. Ask for at least the size the message names. The reply carries it as min_disk_gb, and the database shows it before you ask, in the dashboard and in the API. How a shrink runs, and what it stops, is in Shrinking a disk.

An older CLI refuses every shrink itself, before anything is sent: disk cannot shrink from 20 GB to 5 GB. Update the CLI, or shrink from the dashboard.

A Valkey disk cannot shrink at all yet (see Valkey). CLI v0.13.0 or later refuses a smaller --disk-gb itself, before anything is sent:

❌ A Valkey disk can grow, but it cannot shrink yet. cache keeps its 2 GB disk.

The API answers any smaller size with 409 and code: shrink_unsupported.

App tier too small for its memory

An app can move to a tier with less memory only if the most memory it used in the last 7 days fits in 90 % of that tier’s memory. A smaller tier is refused with 409 and code: tier_too_small, and nothing changes:

What it means. An app that needs more memory than its tier allows is stopped and restarted when it runs out, so the platform refuses the move rather than let the app crash. The peak is the highest any one of the app’s pods reached, across restarts and deploys in that week.

The fix. Pick the tier the message names; the reply also carries it as min_app_tier. To get onto a smaller tier, lower the app’s memory use and try again once the higher readings are more than 7 days old. See Change Site Size.

A 503 with code: metrics_unavailable means the app’s memory use could not be read just then. Nothing was changed; try again shortly.

Signup capacity reached on an auth app

This one surfaces to your end users, not to you — it’s returned by your auth app’s register endpoint when a new user tries to sign up:

What it means. Each auth app is sized by a capacity bracket that caps the number of registered users it can hold. When the app reaches that cap, new signups pause — registering the next user is rejected. Everyone already registered is unaffected: login never checks the cap, so existing users always sign in, even at a full bracket.

The fix. Raise the auth app’s capacity bracket to a larger one — a bigger bracket reserves more points but reopens signups immediately. Because this rejection is your end users hitting a wall, it’s worth moving to the next bracket before you reach the cap. See ghayma auth create for how brackets are sized and priced, and Auth pricing for how the bracket maps to points.