Reporting something that is broken

What makes a bug report answerable

A good report is three sentences and a screenshot. What you did, what you expected, and what happened instead. The third one is the one people leave out, and it is the one that decides how fast this gets fixed.

Details that genuinely help

The exact wording of any error, rather than a description of it. Error text is searchable; "it said something about a token" is not.
Which service and which page. The URL is ideal.
Whether it happens every time. A fault that happens once in ten attempts is a different problem from one that happens always, and they are chased differently.
Your browser and device, roughly. "Firefox on Android" is enough.
When it started. If it worked yesterday, that narrows it enormously.

Screenshots

Attach up to five files to a ticket. Images have their location data removed before they are stored, and they are re-encoded, so what reaches us is the picture and nothing else that was travelling with it.

Please check a screenshot before sending it — the same screen that shows the bug often shows an email address or a document name you would rather not send.

What happens next

The ticket goes into the same queue as everything else and a person reads it. If it is a real fault you will be told so; if it turns out to be working as intended you will be told that, with the reasoning, rather than left guessing.

Did this not answer it? Open a ticket and a person will read it.

Help centre Your tickets Contact without signing in Privacy Terms