Credits and going live

Your plan carries a daily allowance of credits. Runs draw from it, the dashboard shows what you have used today, and it resets daily at 23:55 UTC.

Check what 23:55 UTC means for your users. If they are in a different timezone, their allowance may reset in the middle of their working day, or run out in the afternoon.

Before you launch

• Watch the daily usage. The dashboard shows what you have used against your allowance, which is the number that tells you whether your estimate was right.
• Handle running out. Decide now what your product does when a run is refused. Failing quietly is the worst option, and the one you get by default.
• Separate your keys from your users' work. Every run through your credentials counts as yours, including the ones somebody is abusing.
• Pin the version. Take the version index deliberately, so a toolchain update does not change output your tests depend on.

Failure is not one thing

A program that does not compile, a program that runs too long, and a request that was refused are three different outcomes, and users read them very differently.

Worth separating in your product:

• The program was wrong. Show the compiler output. This is the user's to fix, and the most common case by far.
• The program ran too long or used too much. Say so plainly. Users assume a crash otherwise.
• The request was refused. That is yours, not theirs. Tell the user the service is unavailable.

What next

The API reference has the field-by-field detail: every parameter, the language list, and what each error means.