Issue with Copilot
Issue Report: Plotting Engine Fails to Generate Charts Summary The chart‑generation feature in Copilot intermittently fails to produce output. When requesting visualizations such as radar charts, bar charts, histograms, or other plotted graphics, Copilot often returns an empty result with no error message or explanation. Observed Behavior Requests for plotted charts sometimes return "" (empty output). No error message is provided, making troubleshooting impossible. The failure occurs even with simple, valid datasets and straightforward instructions. Conceptual or AI‑generated diagrams work consistently; only plotted charts fail. Expected Behavior Copilot should reliably generate charts when provided valid data and instructions, or provide a clear error message if the request cannot be completed. Impact This issue prevents users from visualizing structured datasets and reduces confidence in Copilot’s ability to produce quantitative graphics. It also forces users to retry multiple times or switch to non‑chart visualizations. Request Please investigate the stability of the chart‑generation environment, particularly around sandbox execution and rendering reliability. Adding explicit error messages when chart generation fails would also significantly improve usability.Lessons Learned #555: The First 60 Seconds of a Production Incident: Stop, Scope, Correlate
When a critical production incident starts, the first message we often receive is something like: “The database is down.” At that moment, everything suddenly becomes urgent. Engineers open monitoring dashboards. Someone starts checking logs. Another person reviews CPU and memory. Someone else asks whether there was a deployment. Connections are tested. Metrics are queried. Teams are contacted. All of these actions may eventually be necessary. But there is a more important question to answer first: What exactly does “down” mean? After working on many production incidents, one lesson becomes increasingly clear: The first 60 seconds are not about solving the incident. They are about defining the incident. A vague problem description can send troubleshooting in many different directions. A precise problem statement dramatically reduces the investigation space. This article describes a simple approach that can be applied during the first moments of an incident: Stop. Scope. Correlate. 1. Stop: Define What “Down” Actually Means The first mistake during many incidents is assuming that everyone understands the problem in the same way. Consider the statement: “The database is unavailable.” That statement could mean many different things: Applications cannot establish new connections. Existing connections are still working, but new connections fail. Queries are timing out. A specific login cannot authenticate. One database is inaccessible. One application is failing while other applications work correctly. Performance degradation makes the service appear unavailable. The application returns HTTP 500 errors, but the database itself is healthy. Connections fail intermittently. A failover is occurring. DNS or networking issues prevent the application from reaching the database. These scenarios require completely different investigation paths. Before opening ten different tools, try to transform the original statement into something more specific. For example: Instead of: “The database is down.” Try to reach something like: “Since approximately 14:32 UTC, new application connections to Database A have intermittently failed with login errors, while existing sessions remain active.” Now we have something we can investigate. The problem statement contains: a timestamp, a specific database, a specific symptom, affected connection behavior, and an indication that the issue may be intermittent. That is already much more valuable than the original alert. 2. Scope: Determine the Blast Radius Once we understand the symptom, the next question is: Who or what is affected? This is sometimes called determining the blast radius. The scope can immediately eliminate entire categories of possible causes. Ask questions such as: Is one user affected or every user? Is one application affected or several applications? Is one database affected or all databases? Are all connection types affected? Are existing connections healthy while new connections fail? Are only specific clients or drivers affected? Imagine the following situation. Application A reports database connectivity failures. However: Application B connects successfully. SSMS connects successfully. Azure metrics show the database is available. Existing sessions continue executing queries. This changes the investigation dramatically. The problem may not be: “Azure SQL is unavailable.” It may instead be: “Application A cannot establish new connections.” That distinction is extremely important. A large percentage of troubleshooting time can be saved simply by identifying the correct scope early. 3. Build the Timeline The next critical dimension is time. During an incident, timestamps are evidence. Ask: When did the issue start? Is there an exact timestamp? How long did it last? Is the issue continuous or intermittent? Did the problem recover automatically? Did the issue occur once or multiple times? Was there another event immediately before the problem? A good incident timeline may look like this: 14:31:52 UTC – Application operating normally 14:32:08 UTC – First connection error reported 14:32:10 UTC – Database failover detected 14:32:14 UTC – Additional login failures 14:32:18 UTC – New connections begin succeeding 14:32:20 UTC – Application fully recovere Now the investigation is no longer based on assumptions. We have a five-to-ten-second window that can be correlated with platform telemetry, database events, application logs, networking information, and deployment history. Without the timeline, engineers may analyze hours of logs. With the timeline, the investigation becomes focused. 4. Correlate Before Changing Anything The next step is correlation. Once we understand the symptom, scope, and timeline, we can ask: What changed at the same time? Useful correlation sources may include: application deployments, infrastructure changes, configuration changes, database failovers, scaling operations, maintenance events, firewall changes, authentication changes, networking events, DNS changes, resource utilization, query regressions, blocking, deadlocks, connection pool behavior, driver updates, platform events. etc The key word here is correlation. It is tempting during an incident to immediately change something. For example: restart the application, restart a service, scale the database, clear the connection pool, change configuration, rebuild an index, modify a query, fail over manually. Sometimes these actions are necessary. But every change also modifies the evidence. A restart may restore the service while simultaneously removing valuable diagnostic information. Whenever possible: Collect evidence before changing the environment. 5. Use Multiple Sources of Evidence Production incidents rarely provide the complete answer in one telemetry source. A better approach is to correlate multiple sources. For a database-related incident, we may investigate: Application telemetry Application logs may reveal: connection failures, authentication errors, request latency, retry attempts, timeout exceptions, HTTP errors, dependency failures. Platform metrics Cloud metrics may help determine: service availability, CPU utilization, storage pressure, connection count, throttling, resource saturation. Database telemetry Database-level information may include: active sessions, waits, blocking, query performance, login failures, failover events, resource statistics. Query Store For performance incidents, Query Store can be extremely valuable. It may help identify: query regressions, plan changes, increased execution duration, abnormal CPU consumption, changes in execution frequency. Deployment history Always ask: What changed recently? Many incidents have a strong temporal relationship with: application deployments, schema changes, configuration modifications, infrastructure updates, new releases, security changes. The goal is not to assume that the most recent change caused the incident. The goal is to determine whether the events correlate. 6. Avoid Starting With a Tool One common troubleshooting pattern is: “Open the monitoring portal.” or: “Run this query.” or: “Check this log.” Tools are essential, but tools should follow the investigation strategy. The investigation should determine which tool we need. Not the other way around. If the problem is authentication, the investigation path may focus on: login errors, authentication configuration, identity providers, user mappings, connection strings. If the problem is performance, the investigation may focus on: Query Store, waits, blocking, execution plans, resource utilization. If the problem is connectivity, we may investigate: DNS, network paths, firewalls, drivers, retries, connection pools. A clear problem definition tells us where to look. 7. Ask the Same Questions Every Time One of the most effective improvements teams can make is standardizing the first questions asked during incidents. A simple initial checklist could be: Symptom: What exactly is failing? Scope: Who or what is affected? Timeline: When did it start? Error: What exact error message or error code is being returned? Frequency: Is the issue continuous, intermittent, or already recovered? Changes: What changed immediately before the incident? Evidence : Which telemetry sources can confirm the behavior? These questions are intentionally simple. During a high-severity incident, simplicity is valuable. 8. The First 60 Seconds Framework We can summarize the approach in four steps. 1. Define: What does the reported symptom actually mean? 2. Scope: Determine the blast radius. 3. Timeline: Identify exactly when the problem occurred. 4. Correlate Connect the symptom with telemetry, events, and recent changes. Only after these steps should we decide the deeper troubleshooting path. 9. Speed Is Important, but Direction Is More Important During critical incidents, teams naturally want to move quickly. That is the correct instinct. But speed without direction can create noise. Ten engineers investigating ten different theories at the same time may generate enormous activity without producing clarity. A well-defined incident allows teams to divide the investigation intelligently. For example: One engineer investigates application telemetry. Another checks database telemetry. Another reviews platform events. Another investigates recent deployments. Another builds the incident timeline. All of them are now investigating the same defined problem. That is very different from everyone independently trying to determine what the problem might be.
Which Accessible Source Can Reliably Return Current Date, Time, Timezone and UTC Offset?
Question for Microsoft 365 Copilot experts I am trying to implement a reliable "Current Time Validation" control inside a Microsoft 365 Copilot workflow. The requirement is to obtain a machine-readable and repeatable timestamp containing: - Current date - Current time - Time zone identifier - UTC offset For example: 2026-09-16T18:09:00+08:00 Timezone: Asia/Shanghai UTC Offset: +08:00 My goal is not a human-readable world clock page, but a source that Microsoft 365 Copilot can actually access and consume reliably during execution. Business context: The timestamp is used as a mandatory validation gate before generating operational reports. If the timestamp is wrong, downstream conclusions may become invalid because greetings, operating-hours logic, OOO/PTO analysis, and action ownership are all time-dependent. Problems encountered so far I have already tested several approaches and found multiple reliability issues: 1. Conversation context is not a reliable clock source. Copilot may retain or reuse a timestamp from the beginning of a conversation rather than reflecting the actual current time. 2. External "current time" web pages are problematic. Some sites appear to return cached/indexed content when accessed through Copilot, producing timestamps that are clearly inconsistent with real-world elapsed time. 3. Human-readable sources are insufficient. I need a source that returns structured data which can be validated programmatically. 4. Timezone information alone is not enough. The solution must provide: - current date - current time - timezone identifier - UTC offset 5. The source must be repeatable. Two consecutive queries should return updated timestamps reflecting actual elapsed time. Questions 1. Among the data sources that Microsoft 365 Copilot can realistically access today, which source can provide: - date - time - timezone - UTC offset in a machine-readable format? 2. Is there any Microsoft-native source (Microsoft Graph, Outlook, Exchange Online, mailbox settings, tenant settings, calendar services, etc.) that exposes this information directly? 3. Which source would be considered the most reliable and repeatable for workflow-validation purposes? 4. Has anyone implemented a trusted "current time authority" pattern for Microsoft 365 Copilot or Copilot Studio agents? 5. Does Microsoft 365 Copilot have access to a real-time clock source that is guaranteed to be refreshed at query time rather than returning indexed or cached timestamp information? The objective is to establish a trusted and auditable timestamp before generating business reports, task summaries, or workflow decisions. Thanks in advance.
Copilot chats listed, but no longer available.
After installing the latest Copilot (September 2026) some of my chats have become corrupted. In the Android phone app, the Windows 11 app and on copilot.microsoft.com they are listed, but impossible to open delete or rename. I get : "This chat is no longer available". I have several older and newer chats that work just fine. I think the ghosts was created the same day as the new version was installed on my phone. The automatic installation process did not work well. Had to uninstall and manually reinstall from Google Play. I have chatted with Microsoft Support about it, and they admit it may be a server-side problem. Is there anybody with a similar problem? Or maybe somone has a solution? That would be great!Unpacking Endpoint Management: Episodes Available On Demand
Over the course of the Unpacking Endpoint Management series, we brought together experts from across Microsoft Intune, Security, and Customer Experience teams to share practical strategies, lessons learned, and honest conversations about modern endpoint management. While the series has now concluded, the insights remain as relevant as ever. We invite you to explore past episodes on demand and continue connecting with the Intune community through Tech Community, Microsoft Learn, and future opportunities to engage with Microsoft experts. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, hosted the series alongside Rachelle Blanchard. Together, they brought a strong mix of technical expertise, community engagement, and customer perspective to each episode. Rachelle helped surface real customer questions and guide conversations toward practical outcomes, ensuring each discussion reflected how endpoint management works in the real world. Thank you to everyone who participated Thank you to everyone who participated in Unpacking Endpoint Management and helped shape the conversations throughout the series. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Policy: from hybrid to cloud-native Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand! Watch on demand All episodes of Unpacking Endpoint Management are now available on demand via: aka.ms/JoinUEM. The series brought together experts from across Microsoft Intune, Security, and Customer Experience teams to share practical guidance, lessons learned, and real-world experiences from endpoint management. Continue the conversation While Unpacking Endpoint Management has concluded, there are many ways to stay connected with the Intune team and broader community. Join the Microsoft Intune Community here on Tech Community, and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to engage with experts, discover new content, and stay informed about the latest Intune guidance, best practices, and innovations. A Note from the Team Thank you for being part of the series. We're incredibly grateful to our customers, IT professionals, community members, guest speakers, and Microsoft experts who helped make Unpacking Endpoint Management such a valuable experience. Your questions, feedback, and real-world insights shaped every conversation and helped create meaningful discussions for the broader endpoint management community. Although the series has come to a close, our commitment to listening, learning, and engaging with our community remains unchanged. We look forward to continuing those conversations through the Microsoft Intune Community, Tech Community blogs, Microsoft Learn, events, and future opportunities to connect with Intune product, engineering, and customer success teams. Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunityUpdated Copilot app doesn't work with Work account
There was an update to the Copilot app on Oct 3, 2024 (1.0.4.0), and now the app is acting weird on my Copilot+PC work laptop. I press the dedicated Copilot button and expect to have Copilot open from the right. Instead I get a centered screen (which by the way is this address: https://copilot.microsoft.com/?dpwa=1 ) telling me "It looks like you're signed in with your work account. The Copilot experience for work is now at copilot.cloud.microsoft." There is also a button "Go to Copilot for work" which goes to this address https://copilot.cloud.microsoft/?fromCode=pwa, but funny enough, it doesn't redirect within the window but instead opens the address in the Edge browser!? 🤷♂️ In comparison opening https://copilot.microsoft.com/ in the browser navigates directly to the new address for the Copilot experience for work, no issues. Why doesn't the app just redirect directly to the new address for work accounts so I can use the Copilot button as intended? Thanks!
Request to Reconsider Russian Speech Recognition Support in Windows and Copilot
I would like to provide feedback regarding the absence of Russian speech recognition support in modern Windows and Copilot experiences. Russian is not limited to a single country and should not be viewed exclusively through a geopolitical lens. It remains one of the most widely spoken languages in Europe and is used daily by tens of millions of people across numerous countries, including EU residents, immigrants, international businesses, and users throughout Eastern Europe, the Caucasus, Central Asia, and other regions. As a Windows 11 Enterprise user, I was surprised to discover that Russian speech recognition is no longer available as a Windows Speech language package. On my Windows 11 Enterprise 25H2 installation, the Language.Speech~~~ru-RU package is not available at all, while speech recognition packages continue to exist for many other languages. As a result, Russian-speaking users are unable to fully use Voice Typing and certain voice-driven Copilot experiences. This creates a significantly worse user experience compared to competing AI platforms such as ChatGPT and Google Gemini, both of which currently provide high-quality Russian speech recognition without requiring additional configuration. From a business, accessibility, and user experience perspective, limiting support for a language spoken by so many people is difficult to justify. Regardless of political considerations, Russian remains a major international language used by customers, professionals, students, and businesses across many countries and regions. The current situation may unintentionally encourage users to choose competing platforms that offer broader language accessibility and voice capabilities. I respectfully ask Microsoft to reconsider its current approach and evaluate restoring or expanding Russian speech recognition support in Windows, Voice Typing, and Copilot services. Language support should be guided primarily by user needs, accessibility, inclusiveness, and product competitiveness. Thank you for your consideration.
Microsoft Copilot 365 Personal Premium limits
In my Copilot Notebook, I deliberately loaded 20 PDF files in order to test Copilot’s grounding behavior across the full set of available references. At the time this testing setup was created, 20 references represented the effective grounding limit described for Copilot Notebooks, meaning that these references were expected to form the source base used by Copilot when generating grounded responses. The references consisted of fully functional, original academic textbooks containing relevant and up-to-date scientific information, mostly published within the last ten years. Importantly, the sources do not differ from one another in terms of accessibility, file type, availability, or how they were added to the notebook. They are all PDF files, they are all available in the same environment, and there is no obvious difference in access conditions that would explain why some are consistently used while others are repeatedly treated as inaccessible, unavailable, summarized, or skipped. The purpose of the test was therefore not simply to see whether Copilot could access 20 files, but whether it could actually ground its answers in the complete reference set when explicitly instructed to analyze all available sources. Despite this, in approximately 99.9% of my tests, Copilot appears to ground its responses in only 3 to 5 of the 20 available references, often repeatedly using the same documents. When I ask what happened to the remaining sources, Copilot gives different explanations. Sometimes it says that it does not have access to certain files. Sometimes it says that it only received a summary of the file. Sometimes it says that a step involved in retrieving or processing the information failed. The way Copilot explains this often makes it sound as if access to the uploaded files depends on some external or intermediate system, rather than being something Copilot itself can directly control. This is difficult to understand from a user perspective because the files are already uploaded into the Copilot environment and were specifically provided as source material for analysis. The practical result is that a task explicitly requesting analysis of 20 sources often produces an answer based on only 3 to 5 of them. For academic or research use, this is a serious limitation. If 15 to 17 out of 20 carefully selected sources are not actually examined, then the final synthesis cannot realistically represent the full source base. This also creates uncertainty about what Copilot means when it claims to have used the provided materials. My question to Microsoft is: Is there a technical limit on how much information Copilot can actually retrieve, open, and analyze from uploaded files during a single task or session? If such a limit exists, what is that limit? And why, when 20 valid PDF sources are uploaded and Copilot is explicitly instructed to analyze all of them, does it so often appear to open only 3 to 5 files, while describing the others as inaccessible, summarized, or unavailable because some retrieval step failed?Microsoft Copilot 365
To Microsoft: Serious Concerns Regarding the Actual Capabilities of Microsoft Copilot Microsoft, After 12 consecutive days of intensive testing of Microsoft Copilot, for approximately eight hours per day — around 96 hours of practical use in total — I have serious concerns about the accuracy of the way Copilot's functions and capabilities are described and presented by Microsoft. What I have observed in actual use is repeatedly and substantially different from what the product is presented as being capable of doing. This conclusion is not based on a single unsuccessful prompt, an isolated error, or a short test. It is based on repeated testing over many days, involving continuous academic, analytical, document-based, and multi-step tasks. One of the most serious problems is Copilot's inability to reliably maintain and use conversational context even within the same active session. For example, Copilot can generate a substantial piece of text and, in the immediately following interaction, claim that it cannot see or access that same text. It may ask the user to provide again information or content that Copilot itself generated only one response earlier. This makes it impossible to rely on the system for genuine sequential work. During testing, the same general problem has appeared in different forms: Copilot fails to return reliably to earlier tasks, loses access to information already established within the conversation, fails to connect consecutive instructions, and sometimes behaves as though previous parts of the same active session do not exist. This is particularly serious when Copilot is used for academic or research work. A workflow may require the system first to generate or analyse material, then classify it, compare it with another part of the work, identify its sources, reorganise it, and finally continue developing it. If Copilot cannot reliably access the result of the immediately preceding step, such a workflow becomes fundamentally unreliable. After approximately 96 hours of direct testing, it is increasingly difficult to regard these problems simply as occasional technical limitations. The discrepancy between Microsoft's descriptions of Copilot and the behaviour actually observed during sustained use is substantial enough to raise a much more serious question: whether the functions and capabilities attributed to Copilot in Microsoft's product descriptions accurately represent what the system can actually and reliably do in normal use. From the user's perspective, the current experience creates the impression that Microsoft's claims about Copilot's capabilities are misleading. A capability should not be considered a genuine product capability merely because the system can occasionally perform it under favourable conditions. If a feature is presented to users as part of the product's functionality, users should reasonably be able to expect that functionality to operate consistently enough to be relied upon. After 12 days of testing, that has not been my experience. The difference between the advertised or described capabilities and the actual behaviour of Copilot is not minor. In several fundamental areas — particularly conversational continuity, access to previous work within the same session, multi-step task execution, and reliable reuse of previously generated content — the practical experience does not correspond to the expectations created by Microsoft's descriptions of the product. After nearly 100 hours of testing, I am therefore questioning not simply the quality of Copilot, but the accuracy and transparency of Microsoft's representation of what Copilot is actually capable of doing. If Microsoft describes Copilot as possessing capabilities that repeatedly cannot be reproduced in sustained real-world use, then the issue is no longer merely whether Copilot occasionally makes mistakes. The issue is whether users are being given an accurate representation of the product they are being asked to use and pay for.
