Atlassian Statuspage updates that post themselves.
A confirmed failure opens the incident on your Atlassian Statuspage and turns the affected component red, without anyone logging in. Uptimia re-checks the failure from other probes first, so “is it just me?” is answered before the first refresh.
Overview
Last 7 DaysBefore you know the cause
Waiting until you understand the problem feels right. But minute one’s question is never “why” — it is “is this on your side?”, and that one is answerable the second the outage is confirmed, long before anyone can explain it.
Seventeen minutes of nobody knowing
Nothing in those 17 minutes is anybody’s fault: someone has to notice, believe it, find the login and choose their words — while every customer who hit an error is deciding what to do.
Posted from outside your network
The automatic post is deliberately plain — an incident under investigation, one component red. It buys twenty minutes to write the sentence customers remember, not field the same question.
The release that broke sending
09:14 on a Tuesday, the busiest hour of the week. A transactional-email API shipped a release at nine, and a connection-pool setting has started returning 503s to European customers — the ones whose own products send receipts through it.
Three values from the API screen
Uptimia calls the Statuspage v1 API directly: one request creates the incident on your page, a second sets the status of one component. Everything it needs sits on two screens inside Statuspage, and none of it is code.
Copy the API key and page ID
In Statuspage management, open the user menu at the bottom left and choose API info. The API key and page ID sit side by side — the two values that let Uptimia post to this page and nothing else.
Name the component that should turn red
Optional, but worth the minute. Open Components, Edit the one this monitor drives, and take the ID from the end of the browser URL — like kx8qx2y35lnl. Blank posts the incident only, no component.
Test on a page nobody watches
The Send test button posts a real incident to the page you pointed at — impact none, but visible to anyone reading it — and puts the component into maintenance. Use a staging page, or delete the test incident, then attach your monitors.
Connect Atlassian Statuspage
The Help Center shows where the API key, page ID and component ID live — and exactly how an incident opens and closes on your page once they are wired up.
- What you’ll need
- Finding your API key and page ID
- Finding a component ID
- Adding the integration in Uptimia
- How incidents behave
What belongs on a public page
All 12 monitor types can drive a status page, but only a few of them answer a customer’s question: can they load it, buy, call the API. Certificate expiry is your team’s job, not a red banner — attach the outward-facing checks.
One integration, one component
Each Statuspage integration stores a page ID, an API key and one component ID, and becomes its own contact in Uptimia. Point the monitors that represent that component at it, and add another integration for the next one.
The incident posts itself.The wording stays yours.
The whole platform on the trial — 12 monitor types, 171+ checkpoints, and a status page that no longer waits for a human.
Two calls. The words stay yours.
Uptimia opens the incident and moves the component. Your wording, your subscribers, your postmortem and the moment you call it over are all still decisions a person makes.
What lands on the page
A confirmed failure posts an incident — Monitoring Alert, investigating, impact critical, and sets the component to major outage. Recovery posts a second incident carrying the total downtime, and returns the component to operational.
Confirmed before it publishes
Nothing goes public on one probe’s opinion. A failure is re-checked from other probes — up to three independent regions have to agree before the incident is posted.
Subscribers are Statuspage’s job
Once the incident exists, Statuspage notifies everyone who subscribed to the page — email, SMS, Slack, RSS — exactly as it does for a hand-written one.
Maintenance stays quiet
Planned windows suppress alerting, so a deploy at 23:00 never opens a public incident.
One incident during a storm
When monitors that share an escalation policy — Professional plan and above — fail together, the page receives one incident, for the check that led the group.
You already have a status page
Uptimia publishes its own status pages on every plan — custom domain, per-monitor history, subscriber updates — so this is for teams already on Atlassian: it belongs on their bookmarked page.
How automatic Atlassian Statuspage updates work
Uptimia watches your websites from 171+ external locations and, when a check fails, calls the Statuspage v1 API with your page ID and API key: it creates an incident on that page and sets the status of the component you named. A confirmed outage opens an incident called “Monitoring Alert” with status investigating and impact critical, carrying the same alert line your other channels receive, and moves the component to major outage. When the check recovers, Uptimia posts the all-clear as its own incident — status monitoring, impact none, with the total downtime — and returns the component to operational. It never edits or resolves the one it opened, so the incident customers are reading stays yours to close. Statuspage then notifies your page’s subscribers as it would for any incident. The component is optional: without one, Uptimia only posts the incident.
It buys time, not words
Uptimia never marks an incident resolved and never edits your words. It states the observable fact within seconds and leaves the explanation, the tone and the closing update to you.
Reported from outside the outage
A status page run from your own infrastructure goes quiet exactly when it matters: whatever took the site down can take the updater too. Uptimia’s probes fail independently, so the page hears it.
What each event does to the page
Three outcomes, and one of them is the reason to test somewhere private first.
See all 12 alert channels →| Event | Incident posted | Component set to |
|---|---|---|
| Confirmed outage | Investigating · impact critical · the alert line as body | Major outage |
| Recovery | A second incident — monitoring · impact none · total downtime | Operational |
| Send test | Investigating · impact none · a real, public incident | Under maintenance |
Atlassian Statuspage integration FAQ
01What do I need from Statuspage?+
02What exactly appears on my page when a monitor fails?+
03Does the incident close itself when the site recovers?+
04Will the test message be visible to customers?+
05Is the component ID required?+
06Which monitors should drive the page?+
07What happens when several monitors fail at once?+
08Can I update more than one page or component?+
09Do I still need alerts for my team?+
10What does it cost, and what if I don’t use Statuspage?+
Your page stops waiting for you
Paste the page ID, the API key and the component ID, test it somewhere quiet, then attach the checks your customers care about. The next time something breaks, the answer to “is it just me?” is already published.