How to report probable bugs or quirks to WRI? What is the standard way to do it? Is there a known list of bugs maintained by WRI? Can we track the status of bugs anywhere?

3 Answers 3


Bugs should not be reported here on this site. If you know that it is a bug, don't post here, contact WRI about it instead ([email protected]).

Questions about how to work around bugs are welcome though.

(I added this information in the wiki a while ago.)

Note: Please don't use the tag for new questions. The idea is that this will be added to questions when the problem is confirmed to be a bug (based on e.g. community consensus). This tag can be useful for many reasons (being aware of problems and knowing how to work around them---I found myself searching MathGroup for some old bug several times to make sure my code won't be affected by it), but we'd like to avoid new users reporting bugs here or adding this tag to problems they think are bugs but really stem from misunderstandings.

  • 2
    I like your idea of a bug-confirmed tag, because it clearly announces that bug isn't just an omnibus complaint tag. However, creating a bug-report tag--which you also suggest--seems contrary to the advice in your note here. If you want to be perfectly clear about usage, how about creating a bug-workaround tag?
    – whuber
    Mar 27, 2012 at 18:34
  • Community consensus is too vague for my tastes. See also here Mar 27, 2012 at 19:38
  • @whuber You're confusing Szabolcs and me. The two-label approach is my suggestion, so Szabolcs' isn't contradicting himself. Alternatively to 'bug-report' I'd suggest the use of 'bug-possible' or something similar Mar 27, 2012 at 20:42
  • My apologies to both of you about the confusion--I guess I have unconsciously lumped all originators of great replies whose handles begin with "S" into the same category :-). And yes, bug-possible is a little clearer than bug-report.
    – whuber
    Mar 27, 2012 at 20:58
  • 1
    This policy seems inconsistent to me, work around should not be the only acceptable discussion. Many well received "bug" questions limit themselves to confirmation in different platforms but end up providing insight on the cause of the problem. Users come here to solve their Mma problems and bugs are clearly one cause of this problems. Having an acknowledgement that the problem exists and in which versions was fixed may not be the ultimate answer, but does help.
    – rhermans
    Oct 23, 2015 at 16:22
  • 3
    Personally I always link to Mma.SE when reporting a bug to Wolfram Technical Support because that provides a broader description of the issue with experiences in multiple platforms and very likely a distillation of the conditions that triggers the problem.
    – rhermans
    Oct 23, 2015 at 16:30

Bug Reporting Revisited

Given the way the March 2018 post of Nasser (169209) has been received (high upvotes, discussion about to be used, close votes because of an essential "WRI technical support issue", chat room accusations and allegations :) ) has triggered my reflection on the accepted answer above, given by @Szabolcs.

I would beg to differ with that answer and would like to provide some arguments. There are reasons pro and con having bug reports here on M.SE and I would like to start with the obvious cons.

Contra Bug Reports

I see these three reasons given against bug reporting on M.SE:

  • Dead-ends By reporting bugs here, they never reach WRI and users will get lazy to report them, since they feel M.SE to be a viable substitute for the "real thing".
  • SE-incompatibility By leading to lengthy and controversial discussions they are not a good fit for the Q&A-rules of SE. Also they often might get closed due to "technical issue for WRI or professional help".
  • Better Places Incompatibility for SE immediately suggests there may be "better places" for bug related discussions; often Wolfram Community seems to be the natural candidate.

So let's have a look:


While this clearly is a danger, keeping people from repeatedly posting an issue is also a chance (we'll be getting there with the Pros). Clearly using should be a "call of civil duty" to file a report at the same time or even earlier and to provide that information clearly visible for all. Then the dead-end threat will be minimized because not seeing a case number eventually will make me file a report to be sure. And further more, seeing the issue pop up here will maybe serve as a reminder for me to report the long-forgotten issue myself.


Certainly discussions do not fit SE, but they are far from being banned. SE's main interest is to make money from its users and their knowledge - pardon me :), is to prevent discussions from spoiling concise and useful Q&A to build a knowledge base. That is why we have chat rooms. And lengthy discussions automatically open such a room. Where is the threat?

Q&A are a perfect match for : Firstly, we ask about whether we were too dumb to read and understand the documentation (not necessarily a proof of low IQ...). Then we ask whether there are workarounds or third party packages or whether there are deeper insights and related issues. The community might be interested in the scope of an issue (operating systems) and we may even in our desperation become interested in other tools and languages to provide a solution (not for long, alas).

While ultimately WRI, of course, will have the definite answer, all of the bug-related questions may well find sensible answers here in that nice and concise way, for which we love SE so much.

Better Places

Well, be honest, are there really better places than M.SE?! While to a degree Wolfram Community is decent, it does not match M.SE in quality, speed, and precision imho. A clear downside: It belongs to WRI. Here we can have anonymity and meet on neutral, third-party grounds -- which is a prerequisite often for openness and honesty. Maybe this is, why we have so many visitors from Illinois? :)

Pro Bug Reports


I hope not to be the only one suffering from a low tolerance to waiting times. But given the average time of responses here, waiting at least 24h for WRI to return with "acknowledged, you will hear from us soon" is simply not an option.

Not everyone is a premier service subscriber entitled to a decent response time.


I firmly believe in checks and balances -- e.g. balance of power: Filing bug reports has something of David against Goliath. I am at their mercy and their good will. Making transparent -- if done fairly (-> SE-rules) -- is a very powerful tool to foster accountability and to increase consumer power. It clearly shows, whether WRI considers an issue worth their efforts and it shows, whether we are alone in our requests.

Given the technological dependencies and the recent "breadth vs. core" developments, the last issue is an important one. M.SE transparency will help me manage technological risk far better than simply watching for marketing output nobody with interest in truth turns to anyway...


If used wisely, both sides -- WRI and users -- may profit greatly from this sites' format: Its rules foster concise and useful bug-reports (at no cost for WRI! -- believe me, their showing up here is no coincidence ...). SE works like a filter, thus irrelevant, long-known issues are not flooding the pipeline. It also clearly and quickly shows the interest among users in an issue (again anonymity and speed!).

Our time is also saved, as there is no public record of known issues (bug-tracker?). Instead of wasting hours in trying out and waiting for a response we will quickly see whether an issue has already been reported and for how long it is known. Then we can decide upon all available information whether to also file a report by referencing to the known and published Case #.

Update: There is another angle to having a bug list here. Most often I read that unless many people complain by filing bug reports, an issue will not be fixed. This waste of users’ time — who after all pay for working software — can only be avoided by having a public list of bugs and case reports. In that case the number of filed reports cannot be used as a proxy for user interest any more. It seems ridiculous to me to be dependent upon a number of filed reports for having an issue fixed whose functionality was advertised to get at my money. Why?


I firmly believe that the pros far outway the cons. In the end, WRI and we as users, may greatly benefit from a publicly visible and useful repository of issues that are to be considered a bug. I saves time, fosters accountability and bundles the voice of the consumer while also improving efficiency on all sides.

The SE-rules work as a filter here and are imo very much compatible with bug reporting.

I would see these words of guidance:

  1. If not in a hurry and you are clear about an issue being a , file a report first!
  2. If you are in a hurry or are not clear about an issue being a or if you consider your reported issue of wider interest for the community, make this a good and relevant M.SE question without assigning the tag, e.g. ask for workarounds, related and deeper issues etc.
  3. Wait for responses and let the community decide to assign the tag .
  4. If there is consensus about the issue being a bug, report it to WRI and publish the results (e.g. case opened, final answer).
  5. If the issue is fixed -- you will be notified -- update the bug-header to indicate this. Also indicate the persistence of your bugs on new releases.
  • 4
    As to lengthy discussions, we've always been more lax here than on other SE sites. Personally, I find the friendly banter that goes on in the comments to be an asset, and helpful in welcoming new people. Also, it can help clarify and/or highlight various aspects of the post itself. I can see why other SE sites are strict about it, but honestly there's a lot of good stuff in our comments.
    – rcollyer
    Mar 20, 2018 at 13:29
  • 1
    TL;DR If a documented feature is not working out as documented (i.e. a bug) then imo it only needs to be reported once to trigger two things: Either the bug gets fixed (after all WRI "promised" this feature in the docs and advertised it) or the documentation gets changed to point out the erroneous behavior. Bugs need to be made public as a service to the customer -- if WRI does not publish them, we should.
    – gwr
    Apr 23, 2019 at 8:19

I saw Sjoerd removed the from this question, so I came here to see what the points of view are. To be clear: I agree with the removal of the tag since it's not a confirmed bug.

On the other hand I would like to have some tag indicating that OP suspects it's a bug. That's the core of the question, not "notebook" as it is tagged now. But it's only indicated in the title, which IMO is not the right place.

I'm for a and a tag. The first one is a better indicator of the status than simply , and I would feel invited to test OP's code to see if I can reproduce reported behavior.

When to switch from to ? How about: when the behavior is confirmed for the same Mathematica version by at least 2 (or 3?) other users?

I would incinerate the tag.

edit (re Mr.Wizard's concerns)
I don't see the problem with neophytes using the tag when it's no bug at all. If it is because he doesn't seem to understand how Mathematica works it can be explained in a comment or answer and the tag removed.

  • 3
    I don't know that I agree with this. There have been quite a few times that a neophyte user thinks something is a bug which isn't; rather than having them tag it "bug-possible" I think it's better to let it unfold naturally. It is entirely helpful to be able to search for confirmed bugs, but I don't know about possible bugs like the one in the linked question. I'm not voting either way yet; perhaps you can address some of my concerns.
    – Mr.Wizard
    Oct 18, 2012 at 9:59
  • 1
    Also, I think this should problem be a question of its own not buried here.
    – Mr.Wizard
    Oct 18, 2012 at 10:00
  • @Mr.Wizard - I posted here mainly as a response to Szabolcs' answer and the comments to that. I agree that it digresses from the original question. I'll update my answer re your concerns.
    – stevenvh
    Oct 18, 2012 at 10:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .