To report a recurring login error, state the service, sign-in method, exact short error text, and step where it appears. Record two local timestamps with timezone and whether the page loops, refuses credentials, or never reaches MFA. Do not paste passwords, one-time codes, reset links, session cookies, or full URLs containing tokens. Check official status and try one controlled comparison, such as a private window, without hammering the login endpoint. A good report helps distinguish account state from a broader authentication incident.
A slow sign-in can involve page loading, identity-provider redirect, MFA delivery, or session creation. Record the approximate duration of each stage using local time with timezone, broad region, network type, and sign-in method. Compare one working region or network if available, but do not call a single slow device a regional outage. Check the official service status and avoid repeated authentication attempts that might lock the account. Share no credentials or precise location. The stage that lags is more useful than a single total-time estimate.
If one retry does not restore login, stop repeated submissions. Note whether the second attempt used the same method, what error appeared, and whether account lockout or a rate-limit message was shown. Record timestamps with timezone, platform, and the last successful login if known. Check the official status page and a safe control such as a private window, but never share password, OTP, recovery link, or session token. The report should identify whether the retry changed the symptom without asking others to reproduce by risking their accounts.
Use the same account and sign-in method to compare mobile and web, then record the last screen or redirect reached on web. Include browser and app versions, local time with timezone, and whether the web session works in a private window. A successful app login does not prove the account is healthy in every channel; web cookies, SSO redirects, and browser settings may differ. Share only cropped screenshots and short error text. Keep full redirect URLs, codes, cookies, and account identifiers private.
When images fail to load, name the page and which image positions are affected. Note the approximate local time and time zone, device, browser, whether text and other assets load, and whether a refresh or another network changes the result. Check whether the problem occurs signed out if that is safe to try. Avoid posting private image URLs or account data. These details help separate a single broken asset from an account, browser, network, or service-wide issue.
Add a timestamped follow-up describing the new state: which function recovered, which still fails, and whether the error message changed. Mention any safe retry or network comparison, but do not repeatedly submit a transaction that might duplicate. If the official status page changed, note that separately from your own observation. Keep earlier details visible so the timeline remains useful. A precise update helps others tell recovery from an intermittent local issue.
Write the exact shareable error text or code, the page or action that led to it, and what you expected instead. Add approximate local time and time zone, device, browser, and whether a safe retry or another network changed the result. Redact account numbers, tokens, and personal data before quoting anything. If the screen is blank, describe whether the browser shows a URL, loading indicator, or network error. Clear text can often diagnose more than a cropped image.
An app and a website can fail in different ways even when they use the same account. Compare one specific action—such as signing in or opening a document—on both surfaces within a few minutes.
Record the app version, browser, approximate local time, region, and the exact step that fails. If only one surface breaks, try a second device or network before treating it as a service-wide outage. Avoid posting account details or screenshots containing personal data.
What action succeeds on one surface but fails on the other?
A sent indicator only shows that your client submitted a message; it does not necessarily mean the recipient received it. Note the local send time, the status shown afterward, and when delivery eventually appears.
Test with one harmless message to a consenting recipient. Compare web and mobile if available, and ask whether the delay affects one conversation or many. Do not send the same important message repeatedly until you know whether earlier attempts may still arrive.
Which status label is visible, and how long has it remained unchanged?
First determine the direction of the delay: event created on the web but missing on mobile, or the reverse. Create a neutral test event with no personal details, then note when and where it appears.
Include the calendar provider, client and version, approximate local time, elapsed delay, and whether the same account is signed in on both devices. A test event that syncs while older events do not may point to a narrower issue than a complete sync outage.
Where was the event created, and which device is still waiting for it?
A recovery update should say what works again, when you observed it, and what you actually tested. Distinguish your own successful retest from a provider's official resolution; they are not the same claim.
Mention any remaining failure, the affected app or browser, and your approximate region if relevant. Avoid sharing account identifiers. If earlier attempts were queued, check whether they completed before repeating an action that could create duplicates.
Which operation did you retest successfully?
Start with one item whose current version you can open directly. Search its exact title, note the result and timestamp, then repeat with filters cleared and a private browser session.
A cached preview, delayed indexing, and a wrong filter can look similar. Record when the item changed, what search shows, and whether another account or device sees the same thing. Do not post private result URLs or document titles.
What current item is missing or showing an old preview?
Describe the download action, not the private contents of the file. Include the service, approximate local time, browser or app version, file type and rough size, and the visible error.
Try one harmless second file if permitted. If only one file fails, access or corruption may be involved; if every file fails, the feature or network is more suspect. Check whether the file appeared in the downloads folder before repeatedly clicking, especially when exports can be queued.
Does another file download successfully?
Add a new reply when you have a new observation: a changed error, a recovered feature, a new time window, or a result from another device or network. Keep the update tied to your original report.
State approximate local time and region, and distinguish what you observed from what the provider confirmed. Repeating the same “still broken” message without a timestamp or changed symptom makes the thread harder to use.
What has changed since your last report?
Trigger one harmless event and note when its alert appears on each device. Compare the same account and event; otherwise the timing difference may come from different settings.
Check notification permissions, battery restrictions, app version, and whether the affected device was online. If the alert arrives on web immediately but mobile much later, describe that boundary in the report. Avoid repeated test actions that create unwanted messages for others.
Which device is late, and by how many minutes?
Note the time playback stalls, how long it stalls, and whether it resumes or fails. Compare one other video on the same service and, if practical, the same video on another device or network.
Include app or browser version, selected quality, approximate region, and local time. A single damaged video, a slow local connection, and a wider service incident need different fixes. Do not share private watch URLs or account details.
Does the buffering affect every video or one title?
For an issue that comes and goes, record each failed attempt and the first successful retry in local time with the time zone. Note the exact action, app or browser, device, and whether the network changed.
A timeline can reveal a recurring window or a device-specific pattern that a single screenshot cannot. Avoid repeatedly performing actions that may later complete, such as purchases or message sends. Compare your observations with official status updates without treating either as conclusive alone.
When did the last failure and recovery occur?
Test checkout only as far as it is safe to do so. Record whether the cart, shipping details, payment selection, and final confirmation each load. Do not repeatedly submit a purchase while unsure whether an order was created.
If the failure begins after choosing a payment method, note the method type without sharing card or account details. Check order history before retrying, and compare another device or browser only if that will not create a duplicate charge.
At which exact step does checkout stop?
Describe the sequence of screens: where you start, what you click, and which page returns unexpectedly. Include browser or app version, approximate local time, and whether private mode or another device behaves differently.
Never post passwords, one-time codes, recovery links, session cookies, or screenshots containing them. Check the official service status before changing security settings. If a login attempt succeeds on another device, say so without assuming the whole service is healthy.
Which two screens keep repeating?
Compare the same feature and time window across broad regions. Ask whether the reports use the same app version or web route, because different clients can make a regional pattern look stronger than it is.
Record local times with time zones or convert them to UTC. Keep locations broad; exact addresses and account details are unnecessary. A few matching reports suggest a pattern, but an official status update or independent checks are still needed before calling it a service-wide outage.
Which feature failed in each region?
Note whether the progress indicator changes, whether the server acknowledges completion, and how long each stage takes. A stalled upload, repeated error, and slow processing after transfer are different symptoms.
Test with one permitted small file and record its type and approximate size. Avoid repeatedly submitting a large file if it might still be processing, and never post private file contents. Compare another network only when safe and practical.
At what stage does progress stop?
Describe which step fails: requesting the email, opening its link, entering a code, or saving the new password. Include approximate local time, browser or app, and the visible error after removing private values.
Do not post the reset link, code, email address, session cookie, or screenshots containing them. Check spam and the provider's official status before requesting many new links; newer requests may invalidate older ones.
At which step does the process stop?
Compare the same action in the mobile app, mobile browser, and desktop browser within a short time window. Note app version, device, network type, and approximate local time.
If the app fails while both browsers work, report an app-specific symptom rather than a full service outage. Check permissions and official status, and avoid repeated actions that may later complete. If changing from Wi-Fi to mobile data changes the result, include that boundary.
Which surface still works?
A broad city, state, or country is usually enough to compare service reports. Add the feature, app or web surface, local time with time zone, and the visible error.
Do not publish a street address, IP address, account identifier, or private network name. If network type matters, “home broadband” or “mobile data” is more useful than naming the household. Several reports from nearby areas suggest a pattern but do not prove a regional outage by themselves.
What broad region and feature are affected?
“The map is broken” can mean a blank base map, missing pins, failed search, wrong position, or routes that will not calculate. Identify the exact step and what appears instead.
Include app or browser, approximate local time, broad region, and whether other parts of the service work. Check location permission only if your own position is wrong; it will not explain a missing public map layer. Avoid sharing exact home or travel coordinates.
Which map action fails first?
Akousa