No More Couldn't Reach the Server at Sign-In

What changed

Sign-in and sign-up now work reliably on the first attempt, including early in the morning or after the app has been idle for a while. A number of users were hitting an intermittent error during authentication — something like "couldn't reach the server" — that appeared most often when opening Niyam fresh at the start of the day. The error did not mean anything was permanently down; a retry usually succeeded. But appearing at all, at exactly the moments when the tool needed to be ready, made it genuinely disruptive. We identified the root cause, shipped a fix, and added monitoring on the authentication path so we can detect any recurrence before users encounter it again.

How to use it

Nothing changes on your side. Sign in or create an account the same way you always have. The fix operates entirely in the background: the authentication service now responds within a normal time window even on the very first request after a quiet period, so the browser never gives up waiting.

If you are on a stable network and you do see a connection error that does not resolve on a second attempt, note the approximate time and reach out through the help link in the app. We now have monitoring on this exact path, and a timestamp allows us to look at what was happening on our side at that precise moment.

Why it matters

Authentication is not somewhere reliability can be approximate. If you cannot sign in, you cannot access your matters, your drafts, your research, or anything else — and the error appeared most often at the exact moments when you needed the tool quickly: first thing before a hearing, or when returning to Niyam between tasks.

The technical cause was a cold-start delay in the authentication service. When the service had not handled a request for some time, the first incoming request could take longer to process than usual as it resumed activity. The browser has a built-in timeout for how long it waits for a response, and it was reaching that limit before authentication completed. A retry worked because the service was already running by then, which is precisely what made the problem intermittent and hard to predict.

We addressed this in two ways. First, we reduced the time the authentication service takes to return to full activity, so even the first request of the day is handled well within a normal browser timeout. Second, we made the sign-in flow more tolerant of a slow initial response, retrying quietly in the background rather than surfacing an error immediately. Together, these changes make authentication consistent regardless of how long the app has been idle.

Good to know

• This fix targets the sign-in and sign-up flow specifically. It complements a broader infrastructure change that reduced cold-start latency across the app more generally.
• If you see a connection error and you are on a poor network — mobile data in a weak-signal area, for instance — that is most likely a local network issue rather than a server problem. Switching connections or waiting a moment and retrying should resolve it.
• We have added active monitoring on the authentication path. If response times start climbing again, we will be alerted before the issue becomes visible to users.
• Your account, saved matters, drafts, research history, and credit balance were not affected by this issue at any point. The error only blocked the sign-in step; it had no effect on anything already stored in the app.