Invoices and requests

This page covers two things that tend to come up together: where you see what is currently costing money, and what to do when the portal will not let you do something yourself.

What the portal shows you

Under Kosten & Nutzung you will find your credit balance, the cost already accrued this month, and your previous invoices. Accrued cost is updated hourly rather than estimated at month end, so you can see where the month is heading while it is still running.

When an invoice falls due, it is settled against your credit balance first. If the balance does not cover it, the remainder is shown as an open amount that you can either pay directly or cover by topping up. You are notified about every settlement.

How credit works in detail (the signup grant, topping up, expiry, refunds) is on what gh0stcloud costs.

Where the cost comes from

It helps to keep the three parts apart, because they behave differently.

The base fee is the same every month and belongs to your account, not to your applications. Infrastructure cost follows what is actually running: more replicas, larger resource requests, more storage and more traffic cost more, and you will see that within hours. Agreed services such as having us operate it, or a migration, appear only where you have explicitly commissioned them.

If a number surprises you, the fastest explanation is usually the most recent change to your application. A raised replica count or a newly created volume takes effect immediately.

When the portal blocks you

Some actions are not enabled for your account. When that happens the portal tells you why and offers you a request. Typical cases:

• more compute, storage or applications than your account currently allows;
• an external destination your application needs to reach;
• your own hostname, or publishing something beyond the standard setup;
• an additional service such as a database that your account cannot yet create;
• a different backup or retention rule for your data;
• a change of operating model.

What makes a good request

Requests are read by people, and the fastest answer is the one that needs no follow-up question. State the value or destination you want, which application it concerns, why you need it, and how urgent it is. If something is in production, say so.

Two things do not belong in a request: passwords, tokens or other secret values (there is a separate path for those that does not pass them around in plain text) and any attempt to work around a check that exists for a reason. If a protection rule is in your way, a request is the right route; writing past the platform straight into Git is not.