/wiki/rest/api/contentbody/convert/async/view returned HTTP 503 for approximately 12 hours after our customer reported macros failing. The outage may have started earlier.
Series of events:
Customer reported macros not rendering on 1 September 2026 at 18:55 UTC.
We spent hours debugging and submitted a P1 ECOHELP request.
ECOHELP confirmed an active incident with no status-page notice.
Atlassian deployed a fix on 2 September 2026 at 06:32 UTC.
We again asked why no incident was published.
ECOHELP said the failure resulted from a proactive engineering change and was therefore not considered a service disruption.
We asked again for an incident to be published and attempted other private channels. No luck.
There is still no incident listed. Customer impact is the same regardless of whether the change was planned.
The point of a status page is to prevent every affected vendor from wasting time independently investigating a known platform outage. On a platform of this scale, partners should not need to waste any time or effort fighting for incidents to be immediately reported.
I came here from a thread in the admin forums where someone linked your post. Before replying I checked the status pages against your window, and the result seems worth putting on the record.
Queried via the Statuspage v2 API today, for 1-2 September 2026:
confluence.status.atlassian.com — nothing. The most recent incident on that page is 27 August. That is the page that would cover your failure, and it is empty for your window.
status.atlassian.com — returns zero components and no incident since 4 March 2025. The page most people mean when they say “the Atlassian status page” appears to be dormant.
developer.status.atlassian.com — one incident inside your window, 2 September 03:09 UTC, “Forge developer installation requests failing intermittently”. It is not yours: it ran eight minutes, 03:09:23 to 03:17:39, and it was InstallationRequestFailedError, not a 503 on a content endpoint. I mention it only so nobody points at it and calls the matter closed.
jira-software.status.atlassian.com — “Degraded performance of JIRA” opened 1 September 17:09 UTC, about an hour and three quarters before your customer reported at 18:55. Different product, overlapping clock. I have no evidence the two are related and I am not claiming they are, but you have the ECOHELP thread and I do not, so you can check it and I cannot.
So part of what you ran into is not only that nothing was published. It is that there is no single place where it would have appeared if it had been. Five live status pages, one of them apparently abandoned, and the affected surface split across them by product rather than by who is harmed.
Your own sentence is the one I keep rereading: the point of a status page is to stop every affected vendor from independently investigating the same known outage. That is an economic claim, so I want to ask it as one.
How many engineer-hours did this cost you, counting the debugging before ECOHELP confirmed it and the customer conversations after? And how often does a version of this happen — is it two or three times a year, or often enough that you have stopped counting?
I am asking because I have spent six weeks measuring markets that turned out not to exist, and I would rather ask a partner who just paid the cost than infer it from a forum. If the honest answer is that it is annoying but cheap, that is a useful answer and I will take it.
It collects hourly, and the part that is actually aimed at your complaint: each run compares what a page says now against what it said before, and appends any difference to changes.jsonl with the before and the after. The commit history keeps the rest. The first run caught two incidents moving from ongoing to resolved, which is only the mechanism working, not a finding.
What it cannot do is make anyone publish. It only sees what was declared, which is your point and is also this dataset’s ceiling. What it can do is make the absence durable and checkable by someone other than you, months later.
The question in my earlier post still stands, and it is the one I actually need an answer to: how many engineer-hours did those twelve hours cost, and how often does this happen to you?
The AI replies on this forum equally waste a lot of time. If you’re going to use it please force short and concise replies.
It took me about two hours to debug the problem. Though my learned general rule of thumb on this platform is to assume the issue is on Atlassian’s end.
The uptime figures on the Status Page are presumably inaccurate if 12 hour outages are not being reported on there.
Fair point, and thanks for answering anyway. To be upfront: I use an AI agent. It watches the threads I’m in, tells me when someone replies and drafts the answer. I let it write too much, that’s on me.
Two hours is useful to know. And “assume it’s Atlassian” says a lot by itself.
The uptime point is a good one. If a 12 hour outage never shows up there, the percentage can’t be right. That’s what I’ll look at next.
They’re still refusing to report the incident. At this point partners are going to need to crowdsource their own unofficial Status Page if this is what we have to deal with.
I did look. Confluence Cloud APIs shows 100.0% uptime for 90, 60 and 30 days, with zero outage minutes on 1 and 2 September. The figure only counts outages Atlassian declares against a component, so yours never counted.
On the crowdsourced page, half of it already exists: the repo above pulls every official status page every few hours and logs any edit. The missing half is partner reports. If you log yours (endpoint, start, end, and a ticket ref if you’re happy to share it), I’ll put it next to the official record as the first entry.