feat: Atlassian status page monitor

[seluard]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Hello there ! @louislam

Not all third party we use provide a simple API endpoint/s to check status, or this third party provide multiple services, potentially not interested in all of them, just the ones that are actually in use and rely on. A part of that, this third party could have different status per region, and could relay on one of them.

The Idea is adding a feature to been able to track third parties services in a way that allways know those are running ok and trigger alerts on them before our services start trigger alarms that maybe are not that easy to pull the thread to the source of the problem.

Base proposal could be create a new monitor type that follow the convention that statuspage.io(not 100% sure) produce and is followed for some products :

• GitHub : https://www.githubstatus.com/api
• DataDog : https://status.datadoghq.eu/api

At the edition of the monitor could be a multi-check list that you can select which ones of the services you actual want to monitor from this third party. All individual monitors could be tag and group by the custom name provide to the third party monitor.

Some other maybe could require particular implementation e.g :

• AWS services: https://docs.aws.amazon.com/health/latest/ug/health-api.html
• Google cloud: https://cloud.google.com/service-health/docs/reference
• Azure DevOps: https://learn.microsoft.com/en-us/rest/api/azure/devops/status/?view=azure-devops-rest-7.1

As far I see, maybe this could be achieved in some cases using HTTP monitor with JSON query, but that will require extra work and not the best user experience or easy IaC configuration.

Please let me know if you think is something that align with the project.

UPDATE

I made a simple POC around this idea with just small changes to allow uptime-kuma to sync with statuspage api that some services providers offer as I mention earlier.

Please, @CommanderStorm, let me know what do you think :)

Fixes #(issue)

Type of change

Please delete any options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• User interface (UI)
• New feature (non-breaking change which adds functionality)
• Breaking change (a fix or feature that would cause existing functionality to not work as expected)
• Other
• This change requires a documentation update

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

[CommanderStorm]

What would you like to implement concretely?
I think this PR-draft is quite unclear in what it wants to add a monitor for.
Basically, what you want is pre-configured monitors for a boatload of services.
I am not quite convinced that we could handle such a feature from a support perspective (there are so many services out there, APIs change, ...).

able to track third parties services in a way that allways know those are running ok and trigger alerts on them

So basically, a monitor with higher ping-rate than the other monitors right?

create a new monitor type that follow the convention that statuspage.io(not 100% sure) produce and is followed for some products
Some other maybe could require particular implementation

What convention are you talking about concretely?
How widely is it followed?

[seluard]

Let me explain with an example, imagine that you're using GitHub acctions to achieve for your CI/CD system and you want to know if that is up and running.

GitHub provides a status page where you can check that actions are UP:

Also, it even provided access to it using API, so what I would like to have in this feature is provide the API endpoint to the monitor edit page, like https://www.githubstatus.com/api, then load dynamically into a checkboxes wich ones are the components I actually want to monitor from this third party, int this example I would just select actions, and it will create a monitor just for check GitHub actions status.

About the convention, looks like they're using statuspage.io and allow access to some API endpoints public, as I mention in the intial description, this two examples, kind of doing the same:

• https://www.githubstatus.com/api
• https://status.datadoghq.eu/api

As a conclusion, I imagine uptime-kuma being the status page for the status pages!

[CommanderStorm]

Okay, let my rephrase my core concearn:

Basically, what you want is pre-configured monitors for a boatload of status pages. I am not quite convinced that this project can handle such a feature from a support perspective (there are soo many status page providers out there, their APIs change, ...).

[seluard]

@CommanderStorm I get your point, that is why I was taking about this kind of statuspage.io api that GitHub or DataDog provides will follow the same schema and should be kind of "stable".

Some others like AWS health ones, I hope they don't break API at daily basis and use versioning to introduce breaking changes.

I understand the concern but still think could be really valuable and maybe be a beta or experimental type of monitor.

[CommanderStorm]

We cannot support one monitor per single service of a single company.
Monitors are currently designed to be something somewhat generic (HTTPS, GRPC, DNS, ...).

I don't think this monitor would

• be maintainable (we cannot maintain hundreds of these!)
• fit into the existing offering

Note

I am not against allowing for config prefabs, such as #1323 but don't think we can physically support
(think of the long term) change suggested in this PR.
The main difference is that for a monitor, you'd expect it to work but for config-profiles, this expectation is not entirely true and debugability (=> hopefully better issues) is better.

I would vote to close this PR despite the effort that @seluard put into this.
A different approach such as #1323 would be a from-scratch effort anyway.
What do others think about this?

[seluard]

We cannot support one monitor per single service of a single company. Monitors are currently designed to be something somewhat generic (HTTPS, GRPC, DNS, ...).

I don't think this monitor would

• be maintainable (we cannot maintain hundreds of these!)
• fit into the existing offering

Note

I am not against allowing for config prefabs, such as #1323 but don't think we can physically support (think of the long term) change suggested in this PR. The main difference is that for a monitor, you'd expect it to work but for config-profiles, this expectation is not entirely true and debugability (=> hopefully better issues) is better.

I would vote to close this PR despite the effort that @seluard put into this. A different approach such as #1323 would be a from-scratch effort anyway. What do others think about this?

Hello there @CommanderStorm !

Thanks for the explanation, but still think this is not a monitor for every single service company provides, it's just a generic Atlassian status page API interface.

I understand the concerns, and I'm ok to close this even I think this feature will be something require future soon :)

Best!