A minimal HTTP endpoint status API written in rust
Go to file
tarneo 790aaf87d8
core,client: Remove some undoable TODO's
Since the Lagged message is sent from the websocket, it would be a bit
hacky to send a new initial status (even if it is doable by cloning the
app state).
An alternative to doing this would be to make clients always open a new
websocket when they get a `Lagged` message.
2024-04-20 12:27:54 +02:00
.github/workflows Add GitHub Actions Rust workflow 2024-03-17 18:39:35 +01:00
swec swec: Allow watching the list of checkers 2024-04-20 11:56:03 +02:00
swec-checker Remove all unwraps and fully implement client CLI 2024-03-14 19:22:04 +01:00
swec-client core,client: Remove some undoable TODO's 2024-04-20 12:27:54 +02:00
swec-core core,client: Remove some undoable TODO's 2024-04-20 12:27:54 +02:00
.gitignore Initial commit 2024-02-13 16:30:29 +01:00
Cargo.lock swec: Allow watching the list of checkers 2024-04-20 11:56:03 +02:00
Cargo.toml Separate into multiple crates and add a checker 2024-02-25 12:58:31 +01:00
README.md Make README clearer 2024-04-03 16:16:50 +02:00
flake.lock Make flake much cleaner 2024-04-07 13:39:56 +02:00
flake.nix Make flake much cleaner 2024-04-07 13:39:56 +02:00

README.md

Swec

Swec is a minimal status page API written in Rust, which means it could be used as the back-end for more minimal alternatives to projects like Gatus or HertzBeat.

It aims to provide a minimal and efficient REST API that can be used by checkers and clients:

  • A checker determine what the status of a service is periodically and sends that information to the API, which stores it in RAM and dumps it to disk too (kind of like an in memory database).
  • Clients can then ask the public facing API what the status of an API is. Obviously, the public API is read-only.

A checker spec as stored on the API server has the following attributes:

  • A human-readable description
  • An optional URL
  • An optional group (in the form of a free string)

A status captured at a certain time has the following attributes:

  • Whether the checked service is up
  • A message, indicating why it is considered in that state

Features

Implemented:

  • Basic API to read and modify statuses and checkers
  • Websockets api to watch for new statuses

Planned:

  • Web client
  • Various checkers