Highlights
Usage now counts every hour your billing period touches, so the credit total on your Usage & Limits page covers the period from its first second. Organizations got the follow-through they were missing last week: the person you add hears about it, so does the owner whose plan pays, and the role picker finally says what a role can do. And we went through the Dashboard and rewrote the messages that were written for us rather than for you.
What's New
Every hour in your period counts
Your billing period starts at the second you signed up. Usage gets measured in fixed buckets. Those two things almost never line up, so the arithmetic mapping one onto the other has to be exact at the edges.
It is now. A period gets broken into whole buckets of the finest resolution still available for each part, nothing split, nothing counted twice. All three places that read usage share one implementation, which is the actual fix. Three copies of the same arithmetic is how one of them gets to be wrong.
What you'll notice: every number on Usage & Limits reads a little higher than it did last week. Same traffic, fuller count. Nobody is pushed over a plan limit by the change. The same arithmetic gates your quota, so it mattered in both directions.
Nobody joins an organization in silence
Organizations landed last week and you could add a colleague, hand them a role, and let them use keys the company pays for. What you couldn't do was tell them. The hint under the form said to go do that yourself.
Two emails now. The person added gets one naming the organization, who added them, what their role can do, and where to leave it if they weren't expecting any of this. The owner gets one when somebody joins, because the organization's keys bill against the owner's plan and one more person spending their credits is their business, not a courtesy. Neither mail goes to whoever pressed the button. You don't need a receipt for your own action.
The owner's notification fires on both paths: somebody added directly, and an invitation taken up at first sign-in, where there's no actor at all because the person let themselves in.
Roles explain themselves too. A line under the picker changes as you choose, and the Role column carries a tooltip covering all three including owner. Choosing between "Member" and "Admin" with no idea what either one can do is how people hand out admin by default.
One step to add a colleague
Type an email address, press Add. If they already use FourA they join right away. If they don't, we mail them an invitation and they're in the moment they sign in. Same button, same confirmation, same answer either way, and the page describes both outcomes in one sentence instead of naming which one applies to the address you typed.
That second dialog is gone, and so is the reply that used to tell you whether an address already had an account here. Whether some arbitrary email is registered with us isn't a question we answer.
The Dashboard stopped writing to the log
"Failed to fetch organizations" is a line for us. It was showing up in front of you.
Thirty-five of those became sentences a person can act on, like "We couldn't load your organizations. Try again in a moment." Contractions everywhere a human reads. "Invalid member id" and its siblings now say what went wrong instead of naming a variable. The console lines they used to be confused with are untouched, because those really are for us. So is the API-shape validation you get back when you're calling us from code, and so are the machine-readable codes the Dashboard branches on.
Emails got the same pass. An invitation asking a stranger to join "an organization" is the mail people bin, so the names of things you chose are back: the account, the key, the organization, whoever invited you. Free-form text a customer typed still stays out of every mail we send.
Under the Hood
Browser was leaking one file handle per rendering session, and it wasn't our code doing it. An upstream dependency closes one of its two log handles, then returns early and skips the second, but only when the caller supplies its own profile directory. We supply one on every launch, which made the leak both guaranteed and permanent.
The patch wraps that single method rather than forking the dependency. It runs the original first and only acts if the handle is still open, so the day upstream moves that line above the return, our patch quietly becomes a no-op. The tests reproduce the leak before the patch gets installed, so the file states what it's defending against rather than just asserting that things are fine.
Practical effect: long-running Browser instances hold their capacity instead of thinning out as sessions accumulate. If you want to control what those sessions look like on the wire, browser profiles shipped alongside this.
Both of the fixes above started in the same place. Something passed a check that wasn't the check that mattered: a green test suite while an hour went missing from every period, a process reporting for duty while it had run out of the one resource it needed. Green is easy to get. The harder question is what your instruments would have to see before they'd go red, and whether they can see it at all.