mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
API functionality #64
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @louislam on GitHub (Jul 27, 2021).
Discussed in https://github.com/louislam/uptime-kuma/discussions/96
Originally posted by TheGuyDanish July 12, 2021
I'd love to see the ability to retrieve, update, remove or add monitors via API calls. Maybe using an API key that's tied to the user. In a way that when spinning up a new docker container or doing an automated workflow like Terraform, the new device could be added to the software automatically.
@Panja0 commented on GitHub (Jul 28, 2021):
API call for putting monitors on pause/unpause for an xx period would be awesome!
We can than include the API call in a script before doing a restart on a server for instance.
@bsord commented on GitHub (Aug 4, 2021):
Commenting as I too would love to see this functionality.
@jtagcat commented on GitHub (Aug 25, 2021):
GitHub Etiquette
@deefdragon commented on GitHub (Oct 7, 2021):
Some things, like that which is visible on the status page, are already readily accessible, just undocumented. The creation and deletion of monitors/notifications are some of the things that are not.
Thus this realistically sounds like a 2 part task.
@hypervtechnics commented on GitHub (Oct 11, 2021):
Another endpoint I'd need is to read the the active incident information
@louislam commented on GitHub (Oct 11, 2021):
No, it should not be used in my opinion.
It is not the same thing, because these are internal APIs which I expected that it should be called from Uptime Kuma only. I could change API without any notices.
@deefdragon commented on GitHub (Oct 11, 2021):
While I understand that the current calls are expected to be Uptime Kuma only, I really think it should be a single API instead of a public API and an internal API. The biggest reason is that maintaining multiple APIs for the same thing is a real pain. (I have personal experience on this from work. We had internal and external APIs for some products, and about one in 5 feature changes resulted in bugs, as changes were made to one API, but done incorrectly, or not at, all to the other).
Having a unified API has some other benefits as well:
I do understand the want to be able to iterate quickly, and change endpoints. This is still possible if the endpoints are versioned: alpha, beta, stable, deprecated etc. and would just require having a system around these changes. Something that should be considered anyways.
The biggest downside I can see is that the auth logic gets more complicated to account for the different ways the API is getting accessed. Given most of the work would be needed with separate APIs anyway, its not the worst thing.
@louislam commented on GitHub (Oct 12, 2021):
Yes, I see your point.
I won't implement two sets of APIs, but as of 1.8.0, I labeled them as "internal APIs" that everyone should not use. In the future, I may re-label them as "public APIs" and documented it in the wiki once it get stable.
@deefdragon commented on GitHub (Oct 12, 2021):
Kuma has changed a lot in the last few months, and will likely keep getting major changes for a while yet. Exposing the APIs now would likely be a pain point for anyone attempting to use them anyway.
I think reaching reasonable feature stability is a fair point to expose the apis. (perhaps as a 2.0 feature? Not sure your intended versioning scheme).
@alexschomb commented on GitHub (Oct 22, 2021):
I couldn't find any explicit mentioning of it, so I'd like to add that it would be awesome to use the API with external monitoring tools like Zabbix, Monitoring Plugins (Nagios, Icinga, Check_Mk), ... That way Uptime-Kuma could be used as the external status page to these internal tools. Another side effect would be that Uptime-Kuma automatically gains thousands of more monitoring options without implementing them manually into this project.
@nicjansma commented on GitHub (Jan 1, 2022):
This is a fantastic project, and I'm really interested in integrating Kuma into Home Assistant and other home-network things. I'd like an API for:
@louislam would you be up for choosing a few core APIs that would be public and supported as such?
@jesperordrup commented on GitHub (Apr 1, 2022):
I would definatly chose otherwise. If you make your internal api and external api the same, you effectly put a stop to rapid development of solution.
I would countinue with the intenal api (for sure)
I would create a the public api as a versionised api /api/v1/methods
Your internal api can expand change and do whatever you need in the speed you need.
The public api - of course just uses the nternal
The public api carefully ensures that it doesnt change / expose features you dont want to expose.
@jiri commented on GitHub (Apr 6, 2022):
I completely agree with the point that if providing a unified API isn't something that can be done fast, it's not worth the benefit. At this point, not having an API renders Uptime Kuma borderline unusable for me, because I frequently get notification of outages whenever a scheduled service update is in place -- being able to pause an unpause monitors with an API call would alleviate this issue completely.
This issue will soon have been opened for a year and new issues requesting an API keep being opened. I hardly see a core set of functionality (like CRUD on monitors) changing in the foreseeable future and I don't see a reason for stalling just because of a private API that doesn't affect regular users.
@redleeder commented on GitHub (Apr 7, 2022):
I agree with the overall sentiment here. Having an accessible API is extremely helpful to developers and provides a ton of out-of-the-box functionality that you otherwise wouldn't have. I would suggest you reconsider the reluctance to implement this as it is a fairly large omission from the project as it stands now (to the point where, despite the otherwise great implementation, I personally would look for alternatives).
@alichaudry commented on GitHub (May 5, 2022):
I love Uptime-Kuma, but it sounds like it's a no-go for a lot of folks here because of its lack of API support.
Something similar to Uptime-Kuma (for my purposes, anyway) while also allowing API access is Gatus. Might be worth looking into for folks who cannot live without API access to their health + monitoring tool.
(Disclaimer: I'm using both Uptime-Kuma + Gatus as I love exploring cool new homelab projects, but I can't wait to rely solely on Uptime-Kuma once API functionality is introduced into the project.)
@anthosz commented on GitHub (May 5, 2022):
Seems a read API only on Gatus so the issue is the same
@GVALFER commented on GitHub (Jun 1, 2022):
i really consider this feature (API) very important. I really love thhe Kuma, but without API, it can not work for us :-(
@Computroniks commented on GitHub (Jun 1, 2022):
I think that something that could be useful here is creating a list of the core APIs that would be useful and that people want. Then we could go about creating a spec using something like the OpenAPI fomat (https://swagger.io/specification/) After that, if we decide a standard way in which endpoints should be implemented, we could then divide up the endpoints between developers to distribute the workload more.
Using OpenAPI has the added benefit that it can be used to generate documentation that can provide examples of how to interface with the API. There are various generators to output it in pretty much any format you like, e.g PDF, HTML, markdown.
@jesperordrup commented on GitHub (Jun 1, 2022):
@louislam any updates on how you think about this?
@anthosz commented on GitHub (Jun 2, 2022):
imo, can be interesting to be able to:
@Computroniks commented on GitHub (Jun 2, 2022):
I have created a gist to act as a sort of list for suggested endpoints to try and help them from getting lost among comments
https://gist.github.com/Computroniks/d04c2f42e430fd9f6656e40626cbdf0e
@iotemylabs commented on GitHub (Jun 2, 2022):
@Computroniks might I add Pause Monitor in the Manage Monitor Endpoint as a POST request?
@rmawhinnie commented on GitHub (Jun 21, 2022):
Uptime Kuma seems like a really neat project, however without an api to create/delete services, and pause/unapause , it creates toil tasks for people :(. keep up the good work,
@vumdao commented on GitHub (Jun 22, 2022):
Unbelivable a high stared opensource project without API to automate things
@C-Duv commented on GitHub (Jun 22, 2022):
You could at least have rephrased your message (ad?) to make it less mean…
@jiri commented on GitHub (Jun 22, 2022):
@louislam This thread is getting somewhat derailed with most comments just re-emphasizing the desire for this feature. May I suggest constraining this issue to collaborators and writing down a definition-of-done for this feature, so it can be tracked properly? 😃
@PhakornKiong commented on GitHub (Jun 24, 2022):
+1
Would love to contribute to writing some of the API. Can we start a draft proposal using OpenAPI spec?
@Computroniks commented on GitHub (Jun 24, 2022):
@PhakornKiong I created a basic list of the endpoints people suggested (https://gist.github.com/Computroniks/d04c2f42e430fd9f6656e40626cbdf0e) and was kind of waiting for some feedback from @louislam before I went on to doing the spec. I will probably create a draft (i.e version 0.0.1) spec at the weekend and put it in with the gist so that I can perhaps get some feedback on the parameters of the different endpoints.
@bluepuma77 commented on GitHub (Jul 30, 2022):
Would love to use
uptime-kuma, but need an API to add 100+ services with URL."Add foundation for API development" https://github.com/louislam/uptime-kuma/pull/1834 seems to be stuck. It only has GET, no POST.
How can we support?
@lucasheld commented on GitHub (Aug 4, 2022):
I have developed an Ansible collection of modules to configure Uptime Kuma with Ansible. Currently monitors, notifications, proxies, tags, monitor tags and status pages are supported.
https://github.com/lucasheld/ansible-uptime-kuma
Under the hood, the Socket.IO API is used to communicate with Uptime Kuma.
The Ansible modules are using a Python wrapper to communicate with the API. This Python module can also be used without Ansible.
https://github.com/lucasheld/uptime-kuma-api
@lionep commented on GitHub (Aug 4, 2022):
Nice work @lucasheld, the clean way to proceed IMO
@vimarshacooray commented on GitHub (Sep 23, 2022):
@lucasheld Thank you!!!
this is the only reason i needed an api on kuma.
@openstep commented on GitHub (Sep 23, 2022):
Could you please @louislam add here a link to where the documentation about available APIs can be found?
I would like to know if there is for instance an API to create an Uptime Kuma user etc.
@zoic21 commented on GitHub (Nov 7, 2022):
Hello,
Any new ? I'am very interest to enable/disable probe by api.
@k1m0ch1 commented on GitHub (Dec 14, 2022):
idk if this will help, but I desperately need the web API for uptime kuma (since my CICD using golang so I need this)
and here we go
https://github.com/k1m0ch1/kuma-uptime-webapi This is actually using @lucasheld wrapper https://github.com/lucasheld/uptime-kuma-api
thanks man @lucasheld
@MedAziz11 commented on GitHub (Dec 14, 2022):
I have developed a REST API wrapper for kuma since it is much needed in my work , with most of its features using the package developed by @lucasheld https://github.com/lucasheld/uptime-kuma-api .
link : https://github.com/MedAziz11/Uptime-Kuma-Web-API
@rwjack commented on GitHub (Dec 24, 2022):
Now that we have maintenance mode, I think the API becomes quite a needed feature.
For example, update scripts could call the API to enable/disable maintenance mode or pause/resume individual monitors.
The API could also be used to quickly create/remove monitors. A bash script could be made, essentially allowing the user to have a "monitor configuration file", which would be good for monitor versioning. If the file changes, the API is called and updates the monitors accordingly.
@Kovah commented on GitHub (Jan 29, 2023):
Are there any plans to implement an API @louislam?
@pbdco commented on GitHub (Jan 31, 2023):
THANK YOU @MedAziz11 !!!!!!!!!!!! Your backend service for the API functionalities Works like a charm!
@e4rthdog commented on GitHub (Apr 7, 2023):
I use Grafana and an API from uptime KUMA would give us the opportunity to keep Kuma simple and focused on what it wants to be, and at the same time it could be extensible to fit other needs. In Grafana i can represent the info as much stretched or compressed i need to and include info from other subsystems in order to give my users the status information i need them to have.
Hoping that we can have an API for reading info and some api endpoints for specific actions , as the ones i have read in this thread. For example the ability to pause/unpause a monitor due to server restart. There is no need to make a full API now and wait until Kuma reaches a stage where a full API maybe build.
@JaviSoto commented on GitHub (Apr 7, 2023):
I am an iOS developer and would love to write an Uptime Kuma app using an API :)
@jjghali commented on GitHub (Jun 11, 2023):
Any update on this?
@Dragonatorul commented on GitHub (Jun 12, 2023):
I used Prometheus to extract and store long-term data, while limiting the data stored by kuna to only 7 days. This helped a lot with the slowness issue in Kuma too, and allowed grafana to use the Prometheus "power tools".
@CrazyHenk44 commented on GitHub (Aug 29, 2023):
Such an awesome project! And then no API, so I can't use it.
If you are worried about not being able to change things as fast as you want, just use an api version number in the url and not support old versions.
Then when you update the code with an incompatible chage in the API, you bump the API number and you force people to also update the calls to the api when they download the new version and you don't have to worry.
@crstin commented on GitHub (Sep 20, 2023):
A CRUD api is a must have. This is very unfortunate.
@CrazyHenk44 commented on GitHub (Sep 20, 2023):
I just need the uptime stats to report to our customers. It's part of the SLA, so I need this automated for all our customers. With stats per day/week, 30 days and 90 days. Without that we can't switch.
@janithcooray commented on GitHub (Sep 20, 2023):
yes, this even my problem. we have thousands of sites and over 4K end points to ping. i wanted to automate this via ansible. then i also wanted to generate reports on deployments that we occasionally send reports. Kuma has some really nice features. the way this is going im being forced to create our own distro of kuma
@shubhankartrivedi commented on GitHub (Sep 26, 2023):
An API is a must!
@storenth commented on GitHub (Sep 30, 2023):
Yeah, kuma must provide users with API to parse and modify existent monitors to integrate with CI services like gitlab.
@CommanderStorm commented on GitHub (Sep 30, 2023):
@storenth @shubhankartrivedi @crstin
Please refrain from posting
+1/ requests for updates things on issues, as this makes issue-management harder.Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.
@CommanderStorm commented on GitHub (Sep 30, 2023):
@janithcooray
With that many endpoint the current (v1) architecture likely cound not cope.
It is yet to be benchmarked how the performance upgrades in v2 have improved upon this state.
@Besstheone commented on GitHub (Sep 30, 2023):
Hello,
You can check https://github.com/MedAziz11/Uptime-Kuma-Web-API or https://uptime-kuma-api.readthedocs.io/en/latest/ as a temporary solution
@janithcooray commented on GitHub (Oct 1, 2023):
yes, even the dashboard is barely usable, had use status pages. only needed the notifications and a small log disaplay so that's enough for now.
but adding and deleting points is a hassle.
@CrazyHenk44 commented on GitHub (Oct 14, 2023):
How does that work? This feature request has almost 3 times more 👍🏻 than any other request. If you indicate you prioritise based on them, you should actually do that, right? Within reason of course. If you don't like the feature and won't implement it, just say so, so we can all move on. There is even a 3rd party that already does it, you merge that maybe.
Hope you can reconsider, it's just such a great product and i want it to succeed.
@georgkrause commented on GitHub (Oct 14, 2023):
For me its really disgusting how people are bragging here how much infrastructure they manage, eg
but still refuse to just contribute or fund the work required to make this happen.
@louislam Just want to let you know that all your work is appreciated and Uptime Kuma is a insanely nice thing in my toolbox, even without API. Keep on the good work!
@louislam commented on GitHub (Oct 14, 2023):
@georgkrause It's ok, I can understand that not everyone can/will understand. Since most of you guys are reasonable, so it is fine. Their opinions are not important.
Anyway, I may decide to try to convert the current undocumented Socket.io (WebSocket) API into HTTP API by wrapping a WebSocket client on server. In this way I hope it won't take too much effort. I also hope it could be released in 2.1.0. (next next version)
PR: https://github.com/louislam/uptime-kuma/pull/3854
@Aj7Ay commented on GitHub (Mar 13, 2024):
Is that possible to create incident using API from shellscript ?
@CommanderStorm commented on GitHub (Mar 13, 2024):
Yes, see the thirdparty api for the moment https://uptime-kuma-api.readthedocs.io/en/latest/ which is mentioned above.
@Tealk commented on GitHub (Jun 1, 2024):
is there anything new about this, the discussion function seems to no longer exist?
I would like to control the maintenance function via API, as I could update all my services via Ansible. This could be very easily integrated
@CommanderStorm commented on GitHub (Jun 1, 2024):
Please refer to https://github.com/louislam/uptime-kuma/pull/3854 our the draft/plan to implement this.
Please refer to #4500 for the things that are needed for the current release and how helping out can help get this done faster.
@Tealk commented on GitHub (Jun 2, 2024):
works for me at the moment, thank you
@paul-uz commented on GitHub (Feb 19, 2025):
Any update on this?
@DenuxPlays commented on GitHub (Apr 2, 2025):
That is really the only thing missing in uptime kuma!
I am using it for over 2 years and it works great but I recently wanted to make some workflows automated like updating services and an API would is the one thing that is missing as I still have to go and create a maintenance for example manually.
Really hoping this is a thing sometime.
@SomeoneVeryCool commented on GitHub (May 13, 2025):
Is this something that will be added in v2?
@jamal-0x1 commented on GitHub (May 23, 2025):
Is there a status api to check the status of Uptime Kuma itself?
I guess I can use
/dashboard@Tealk commented on GitHub (May 24, 2025):
I would find an API to control the checks for automation much more interesting.
@Sammeeeeeeee commented on GitHub (Nov 18, 2025):
This would be fantastic
@pr1ncey1987 commented on GitHub (Feb 26, 2026):
Ive created this which is a bridge server sits in-between kuma and your application - gives its a more traditional REST api.
https://github.com/pr1ncey1987/uptime-kuma-api-v2