Your work backed up daily, every credit explained

Your account, your projects, your storyboards and your credits all live in one database. Each release can update that database's structure, because our containers apply the latest schema when they start. That keeps releases simple, and it means every release is also a change to the database. We wanted losing a day of anyone's work to be impossible.

So the database now has:

• daily automated backups, kept for two weeks;
• point-in-time recovery, so it can be restored to any minute in that window;
• deletion protection, so it cannot be removed by mistake.

We took an on-demand backup before switching it on, then confirmed that the first automated one completed. And we kept a habit from that day: before any release that changes the schema, we take a fresh backup, and the release notes say so.

Every credit movement has two halves. The balance changes in one step, and then a ledger line records why: which film, which reason, how much. The balance is what you spend; the ledger is what lets you, and us, understand it.

The ledger line is now written with the same care as the balance. If it cannot be written on the first try, it is retried after a short pause. If that fails too, we get an error carrying everything needed to write the line by hand, so no movement is ever left without its reason.

While we were there, we added an index on the film each line refers to. The film status tool looks up those lines on every check, so asking how a render is doing became faster too.

A ledger is only as good as the check that reads it. So we added a reconciliation: for every account, does the balance equal the opening credits plus the sum of every recorded movement? Any account where it does not would show up at once, with the largest difference first.

The check accounts for the opening credits every new account starts with, and a test holds that figure equal to the database's own default, so the two can never quietly diverge. On its first full run the reading was zero. Every balance was explained by its events, and a check that reads zero for the right reason is the one you can trust.

When something fails in a render, we want to know before you have to tell us. We chose not to add another vendor. A small reporting function now writes each failure as a structured log line in the format Google Cloud's error reporting understands: severity, stack, service and version, plus the film or account involved.

The platform groups repeats, counts them and can alert us. There is no extra library, no extra key, nothing more to maintain. It is wired into the pipeline's outer failure handler and into the ledger, the two places where a failure matters most to you.

The last fix was about our own checks. The credit-ledger test needed an existing user to run against, and our automated test environment always starts from an empty database. It now creates a temporary user of its own, runs every rule about credits against it, and removes it afterwards. The rules that protect your balance now run on every change we make.

None of this changes what you see on screen, and that is the point. These are the nets under the trapeze:

• check that backups exist, and that the first one worked;
• reconcile money from two independent sides;
• make sure every safety test really runs.

If you build on our API, the developer docs show how credits and refunds appear in each film's status.