All our on-demand cloud resources (compute, storage, IPs, …) are billed per hour.
Except for support subscriptions , which are proposed under a plan pricing scheme, and are billed for a whole month at a time.
Five resource classes are currently billed:
The following resources are currently not invoiced but will be soon:
IMPORTANT: Each of these un-billed resources will be charged in the upcoming months. An exact date is not known yet, but this notice will be updated once details are sorted out.
No, prices stay the same regardless of the location of your resources.
Issued each month.
Our reference billing period is the definition of a calendar month in the Coordinated Universal Time (UTC) timezone.
As for payments, they occur in the first few days of a month, once the invoice is properly
We advertise two sets of prices for each resource class:
Here is how the two prices articulate with each other:
The monthly cap counter of each resource is reset at the start of a month.
All compute instances are billed depending on how long you are running them, at either:
Here are the rates per instance types:
|Compute instance type||Hourly rate||Monthly fixed price|
IMPORTANT: The price given here is the raw, un-bundled unit price of a compute instance. Running a compute instance alone doesn’t make any sense. You need additional resources (IPs, storage, …) to use the instance as a proper server.
A standalone compute instance is of no use if you can’t access it from the network, or without a disk from which to boot from. You need to attach IP address and storage resources to use your instance in the real world.
Prices for a C1 server announced on our pricing page include an additional IP and volume. The total cost of this package is reached by adding up prices from each individual resource:
|Resource||Hourly rate||Monthly fixed price|
|C1 compute instance||€0.002||€1.00|
|Flexible IPv4 address||€0.002||€0.99|
|Volume of 50GB SSD storage||€0.002||€1.00|
Each resource class you’re consuming under this package will be billed and featured separately on your invoice.
Stopping a server (off status) is not enough to stop billing since the resource stays allocated to your account.
IMPORTANT: Beware that powering off or deleting an instance keeps its associated volumes and flexible IP addresses allocated to your account, for which you will be invoiced. Be careful to properly stop or remove these dependent resources to prevent any surprising over-consumption.
Volumes are billed depending on their size and how long you keep them:
Snapshots are billed depending on their size and how long you keep them:
No, images from our ImageHub are free.
If images are free in themselves, you still need resources to run them on (compute instance, storage, IPs…). These resources are billed as usual.
Images or Volumes created from a Snapshot are billed like regular snapshots.
Here is a detailed list of what is considered as start and stop billing events for each resource class:
|Resource||Billing starts||Billing stops||Notes|
|Compute instance||At the moment you click on the “Power ON” button.||When the instance is powered off.||The instance is not billed during its shutdown sequence. A hard reboot will keep the ongoing resource running. On the other hand, powering off a server is considered as a standard stop-start cycle and as such lead to the creation of a new resource, resetting the monthly cap counter along the way.|
|Flexible IP address||When you reserve an IP.||When you cancel the reservation.||This class of IP is billed as long as you keep the reservation open. You’ll be billed whether you are effectively using the IP or not.|
|Dynamic IP address||When a dynamic IP is associated with a running compute instance.||When a dynamic IP is detached from a running compute instance which has just been shutdown.|
|Volume storage||Once a volume has been created.||Once a volume has been deleted.|
|Snapshot storage||Once a snapshot has been created.||Once a snapshot has been deleted.|
Each uninterrupted period between a start and a stop billing event will be considered as a unique resource. It’s the number of these unique resources seen within a month that is displayed in the consumption table of your invoice.
Once you start consuming resources, a
Draft invoice will be produced for the current month, and you’ll receive a notification by mail.
This invoice is then regularly updated through the month to mirror your usages and associated costs.
Your current and past invoices are all available from the control panel:
Below is an example of a typical invoice:
It reads like this:
The legal name of the customer, recipient of the invoice, depends on the B2B or B2C status of the organization.
As such, the name featured on the invoice ends up being the organization or the user who created the organization (i.e. signed-up for a Scaleway account).
Make sure to provide the correct recipient name as well as the account type (B2C or B2B), as this information can not be modified.
The country of residence is a piece of required billing information as it is used to compute taxes depending on your place of purchase.
Setting up your country of residence is part of the sign-up process, and you can’t start consuming resources until you provide it.
Once in place, the country of residence can’t be changed freely from your account page. This is a protective measure to lower fraud because the address has fiscal implications.
If for some reason you’d like to change or fix your country of residence, please open a support ticket and tell us about the reason of your change and the new address.
We’re trying our best to provide estimates of your current month’s usages. This process is not real-time (yet). In the meantime, your consumption and administrative details might not be perfectly reported on your invoice.
This is expected and temporary. The invoice will self-correct if you let it refresh itself after a couple of update cycles.
In doubt, check the Last update field on your PDF. If it’s set in the past, precluding an action, then everything’s normal: your invoice hasn’t seen yet the effect of said action.
The consumption of each resource class is detailed by five columns:
The status of an invoice can be:
Draft: Only concerns invoices from the current month, with resources still running.
Stopped: Same as
Draft but no resources are still running over the corresponding billing period. All invoices for previous months not
Issued yet ends up in this state.
Outdated: Same as
Stopped, only that we know for sure underlying usages have been updated, but the invoice doesn’t take them into account yet. A refresh of the invoice is imminent.
Incomplete: Generally means billing details or payment information are missing or incorrect.
IMPORTANT: If you find your invoice in the
Incompletestate, you should take action as soon as possible. Fix your profile as your account is in danger of being terminated for administrative reasons.
Issued: The invoice is final, has a unique number, and is non-repudiable. A payment request is being processed.
Paid: The invoice has been fully paid, we received your payment. Everything is in order.
IMPORTANT: All consumptions and amounts are considered as estimates, but in
Paidstates, for which the invoice is frozen and immutable.
Counters on your dashboard effectively show that you currently have 1 server running (i.e. 1 compute instance, 1 IP address, and 1 volume):
On the other hand, the consumption table of your invoice features 3 resources of each class:
This difference appears because the resources reported on your invoice consist of the total number of unique resources seen within the month. Unlike your dashboard, which displays the instantaneous value of currently running resources.
The other resources referred to in the invoice are most of the time contiguous sessions resulting from several start-stop cycles. If you’re looking for the underlying details, see how we account for start and stop billing events.
Same thing as above: you started and stopped your server 5 times which produced 5 server sessions.
A session is a continuous run of a server instance, and that’s what we account as a resource on your invoice. This means stopping then starting the same server will produce two sessions, and as a result, two resources will be shown on your invoice.
See how we account for start and stop billing events for more details.
Each resource class possess its own temporal granularity and their usage’s start and stop dates are aligned to these:
|Compute instance||Minute||If usages of compute instances are aligned to the minute, their pricing is based on a 60 minutes sliding window.|
|Flexible IP address||Hour|
|Dynamic IP address||Hour|
Let’s take for example a resource whose granularity is hour, like IP reservations. If you start the reservation at 04:13:34, its usage start date will be rounded down to the closest hour at 04:00:00 in UTC timezone.
Same thing when a resource is stopped. A cancellation of IP reservation at 21:32:47 will see its corresponding usage stop date rounded up to the closest inclusive hour at 21:59:59 in UTC timezone.
As a result, you can’t consume less than the natural granularity of a resource. A start of an IP reservation immediately followed by a stop will account for a whole indivisible hour of usage.
These quantized, rounded timed events are those displayed on your invoices and explain the perceived discrepancies between your action and their reported dates.
Let’s starts with this invoice consumption table:
Looking at the underlying raw telemetry, the C1 session started at
2015-10-05 18:40:35+0000 and was stopped at
2015-10-05 18:49:02+0000. Which is reported on your invoice under the
October 5, 2015 at 6:40:00 PM +0000 → October 5, 2015 at 6:49:59 PM +0000 time range, because of the resource time granularity.
Now if we take the time range quantized to the minute, it effectively accounts for 10 plain minutes of continuous C1 usage. These 10 minutes are referred to as the raw quantity.
The price of C1 compute instances are not attached to this raw quantity but to what is called a bundled quantity. This quantity is derived from the raw quantity, but quantized, at the resource level, to the unit quantity of the resource class.
That’s how by the way we are in a position of billing a sliding window of 1 hour instead of slots of indivisible hours.
In the case of C1, the unit quantity is of 60 minutes. As a result, you should be effectively invoiced for 60 minutes of usages. So why the 300 reported minutes instead of 60? At the hourly price of €0.002, it should cost you €0.002 × 1 hour = €0.002.
The thing is, we can’t feature an invoice line below the currency precision (2 decimals for Euro). So we’re rounding up the total price to €0.01 to make our accountants and auditors happy.
Now invoicing good practices requires us to explicitly have an untaxed invoice line total made up from a quantity multiplied by a unit price. As we don’t want to alter the unit price, we adjust the quantity until we reach the total of the line. This adjusted quantity is what we call the billed quantity and is what’s featured on your invoice.
The same mechanism applies for the IP and storage resource classes, only that the time granularity is different.
All in all, the reason you are noticing these discrepancies is because you are operating at the lower edge of the consumption domain. Only tiny invoices below the currency decimal precision amplify the effect of scalar quantization.
IMPORTANT: Note that the raw quantity and bundled quantity are not featured on your PDF invoice to make it more readable. However, these two intermediate quantities are going to be exposed in billing’s API soon.
We’re trying our best to provide estimates of your current month’s usages. This process is not real-time (yet). Your actions on resources need to percolate from the hardware to the invoice level.
While events propagate, the consumed quantity on invoices might not be perfectly in sync with the state of your resources. Most of the time you’ll not notice the delay.
But in some rare cases, you’ll observe an artificially inflated invoice. That’s because a resource’s stop event has not yet been received or accounted for. The pricing algorithm will then report the resource as still running, thus increasing costs.
This is expected and temporary. The invoice will self-correct if you let it refresh itself after a couple of update cycles, while it’s catching up with new resource events.
No. Invoices are only generated once you start consuming resources.
In most cases, you get a
6004 error if you try to process a payment too many times in a short time frame. The
6004 error is generated by our payment provider to prevent abuses and induce a soft-lock on your account that prevent you to add a new card and process payment for the next 24 hours. Note that this period is extended every time you try to pay during the soft-lock period time frame and will be pushed further
If you face this situation, please make sure to contact your bank and confirm that they are not blocking the payment on their side and then re-try one the soft-lock period is over. If it’s not the case, we encourage you to try processing your payment with another card after the soft-lock period.
You think you have a
Basic account. But what you’re referring to is, in fact, a basic-level support subscription. And indeed, the
Basic support level is for free. But any resources consumed under this plan are still invoiced.
Because we’re a European company, we are required to charge VAT on all purchases made by European individual customers (B2C).
The appropriate VAT rate is automatically applied on your invoice depending on your fiscal residence. Just make sure your administrative details on your profile (postal address, recipient name, phone number, …) are in order.
No other additional taxes but European VAT is collected. If you are not located in one of the 28 member states of the European Union, no other tax will be added to your invoice, per application of EU laws.
European B2B customers are exempted from VAT, as long as they provide a registered VAT number. Just fill-in your VAT registry number on your profile and your invoice will be updated accordingly.
If you fail to provide a valid VAT number, you’ll be considered as a regular individual customer (B2C) and the local rate will apply.
At the start of each new month, all invoices from the previous month are fully updated and ends up either in the
Then we double check the consumption of each resource and make sure all usages are in sync and accounted for. Next, we issue the definitive invoice of the previous month.
Issued, an invoice is non-repudiable and it is content can’t be altered. Amounts are definitive and can’t be revoked. If you’d like to contest the billing of your resources, please act before invoices are
Issued, as we are not in capacity of offering a refund .
Billing periods are aligned to the Coordinated Universal Time (UTC) timezone.
So if you live in a place whose timezone is set before UTC (i.e. western zones, with a negative UTC-XX:XX offset), the billing month might end up to 12 hours before the end of your local perceived month.
You’ll receive a mail notification each time a new
Draft invoice is created for the current month with an estimation of your consumption :
Another notification is send when an invoice from last month gets
Issued and is due:
Unfortunately not. But all mail notifications related to the billing are send from the following identity:
Scaleway billing <firstname.lastname@example.org>. Which makes it easier to re-route them with any standard email client or server.
You probably misread the following notification email:
Issued is part of the accounting vocabulary and means your last month invoice is final, non-repudiable.
For details, see invoice states explanation from this FAQ.
If you replied to a mail notification we sent you, then that expected. These are sent from
email@example.com. See the
noreply there? It means nobody on this planet is going to read your reply.
If you need support by direct emails, please subscribe to the appropriate support plan .
Our Billing’s API is not public yet. We plan to release it in the coming months.
We currently support credit and debit cards from the following networks:
When more than one card is registered in your account, you can designate which one should be billed by default.
It is also possible to pay an invoice with SEPA Direct Debit.
IMPORTANT: Due to a large number of fraudulent sign-ups using virtual, prepaid or electron cards, we currently do not accept these payment methods. When using one of these card types for payment, you might end up with a failed payment and unpaid bill.
The Single Euro Payments Area (SEPA) improves payments across the European Union for both individuals and businesses. A SEPA mandate must be unique to a user, as for a credit card.
IMPORTANT: Unpaid invoices cannot be settled with a SEPA mandate.
To add a new SEPA mandate:
Tick the checkbox to make SEPA Direct Debit as your default payment method.
Credit card data are sensitive data which are required by law to be securely stored.
To comply with such international and local regulations, we rely on an external payment service that is fully certified under the following framework:
When you register a card, we initiate what is called an authorization charge of €2. This is a dummy transaction to check the validity of the card. While it has an amount, this transaction never ends up by a charge.
This procedure is quite common in the world of payment processors but is not standardized. Depending on your bank, this transaction is going to be reported differently on your bank account statement.
Some banks will show you a debit of €2 followed by a credit of the same amount at a later time. Some other banks will never show the transaction at all.
To know when the authorization charge will be credited back, please contact your bank. They are in control of the execution speed, and from our experience, it takes from 1 to 3 weeks for the transaction to materialize in your statements.
Whatever happens, the €2 are never charged, nor debited from your bank account.
These limitations only affect authorization charges. Monthly payments of your invoices are not going to suffer these constraints.
No. A card is strictly personal and can’t be shared between accounts. A card is associated with one account and one only, forever.
You can register as many cards as you need.
The selected, active card is going to be your preferred mean of payment.
Anytime we’ll initiate a transaction, only the one you selected will be considered.
If your active credit card expires, is rejected or became invalid, we’ll never fall-back to another one. Even if the others you registered are perfectly fine. That way, you stay in total control of which payment method takes priority.
Euro is our reference currency of accounting and as such, all prices and invoices are given in Euros.
This doesn’t prevent you to pay in the natural currency of your active credit card. The conversion from your currency to Euros should be transparently handled by your bank.
IMPORTANT: Additional currency exchange fees might be charged by your bank.
Issued invoices are non-repudiable and immutable. We can’t offer a refund on them.
Still, if we found out that you were incorrectly billed for resources you haven’t used, we can offer you a discount on your next invoice.
With discounts applied to your invoice, you might end up with a grand total of €0. In this case, your invoice is going to be
Issued as usual but no payment will be initiated on your active credit card.
As a reminder, the due date of payment is displayed on each invoice once
IMPORTANT: If you are unable to settle your invoice after the due date, your account is going to be suspended and your resources unreachable.
No, the total due for a month is not allowed to be split. Your invoice must be paid in full, with a single transaction.
Because your monthly invoice depends on your consumption profile, we have no way to predict your consumption in advance. To avoid managing a credit balance and keep the billing simple, we do not accept any purchase in advance.
But this transaction might fail, most of the time because of your credit card expired, was rejected or has insufficient funds.
Whatever the reason, we’re not going to re-initiate the failed transaction after the first automatic attempt. Only you have the power to retry a failed payment.
In this situation, you’ll be notified by mail of a payment failure, and invited to initiate a new transaction from your account.
If after several manual attempts you can’t manage to trigger a successful payment, you have the alternative of adding another credit card. But don’t forget to make this card the active one and re-initiate a payment transaction.
IMPORTANT: Don’t waste time when you are notified about a failed payment. You are required to pay before the due date. If you can’t manage to make a successful payment transaction, contact our support team and/or your bank.
If your resources are garbage-collected, the account in itself is not closed and might be re-open.
Some accounts might have been locked-down and still have unpaid invoices attached to them. These accounts can be re-opened by sending a payment for each outstanding invoice.
As for failed payments, login to your account, and click on the link on top of your dashboard, you’ll be redirected to a list of all outstanding invoices waiting for a payment:
All charges we initiate are going to appear on your bank account statement under the
Unfortunately, that’s not the case for American Express accounts, for which our payment requests will bear the
ONLINE~SAS PARIS label. This refers to Online.net, Scaleway’s parent company, but Scaleway really is behind these transactions. We’re currently working on this tiny glitch so in the future our own label will be used instead.