OpenBOM System Status Page Is Now Available

We keep improving OpenBOM, and not every improvement is a new feature inside the product. Here is one that lives outside it.

OpenBOM now has a public system status page at status.openbom.com. You will find a direct link to it in the top navigation of openbom.com and of our Help and Training site. It is public, it does not require sign in, and it shows you whether OpenBOM services are healthy right now.

The Worst Question in Support Is “Is It Just Me?”

Anyone who has run a support organization knows the pattern. Something degrades. The first user notices, checks nothing, and files a ticket. The second user notices, asks a colleague, and files a ticket. By the time our team has confirmed the scope of an issue, we are answering the same question fifteen times in fifteen different threads instead of communicating once, clearly, to everyone.

That is a bad experience for customers and a bad use of engineering attention during exactly the window when engineering attention is most valuable. A status page collapses that entire loop into a single click. You see whether the platform is healthy, you see which components are affected if it is not, and you see what we are doing about it without waiting for a reply

The point is not that a status page prevents incidents. Nothing prevents incidents. The point is that it changes the default from uncertainty to information.

Availability Data Belongs to Customers, Not to Vendors

I have spent a long time in the PLM industry, and I have watched plenty of vendors treat service availability as internal information that gets shared selectively, usually after the fact, usually in a carefully worded email. That model made a certain kind of sense when software ran on a server in your building and the vendor was not in the operational loop at all.

Cloud changed the contract. When you put your bill of materials, your part numbers, your CAD file revisions, and your supplier data into a cloud platform, you are trusting somebody else’s operations team with the continuity of your engineering work. That trust deserves to be verifiable rather than asserted. Publishing status openly is one of the cheapest and most honest ways to do that, which is precisely why it should be table stakes and not a differentiator.

We are treating it as an ongoing commitment, not a launch. The page will improve as we get better at instrumenting what matters to users rather than what is easy to measure.

Where You Will Find It

Two entry points went live this week.

1. On openbom.com, System Status now sits in the main navigation next to Company.
2. On the OpenBOM Help and Training site, System Status appears in the same position in the top menu, alongside Training Courses, Getting Started, Administration, Data Management, and Integrations.

Both take you to status.openbom.com. Bookmark it if you are the person on your team who fields the “is OpenBOM down?” question, because it will save you a message to us and a message back.

The Real Value Comes When Status Enters the Support Flow

A standalone page is useful. A status signal wired into the places where users actually notice trouble is significantly more useful, and that is the next step for us.

We are working to bring status awareness into the notification and support experience directly, so that when something is affecting a service you depend on, you learn about it in context instead of having to go looking. The goal is that our support conversations start from a shared understanding of what is happening rather than from diagnosis. Pedro and the Customer Success team spend far too much of their day establishing facts that a system should simply publish.

There is a broader thread here that connects to how I think about product memory. Context should travel to the person who needs it, at the moment they need it, without a human being having to fetch and retype it. That principle applies to design decisions and BOM changes, and it applies just as much to knowing whether the platform under your work is healthy.

What I Would Ask of You

Check the page, bookmark it, and tell us what is missing. If there is a component you care about that we are not reporting on with enough granularity, that feedback is genuinely useful and easy for us to act on. Reliability communication only works if it maps to how you actually use the product, and you know that better than our dashboards do.

Best regards, Oleg