Gatus

Let hires see which of your endpoints are up or down in Gatus, with uptime, response times and why a check failed, and be woken when one goes down or comes back.

Explore 2 actions and their permissionsExact inputs, sign-in scopes, access limits and approval rules.

With Gatus (open source, on your own servers), a hire can:

see every endpoint Gatus checks, up or down, with its last check and which condition failed ([STATUS] == 200, [RESPONSE_TIME] < 1000…),
read one endpoint: its uptime over the last hour, day, week and 30 days, its average response time, its recent checks, and when it went down or came back.

Hires only read. Gatus keeps its endpoints, alerts and maintenance windows in its configuration file, and its API doesn't change anything, so there's nothing to pause or resume from Roster.

Using Uptime Kuma?

Uptime Kuma doesn't have a supported API for its monitors yet, so it isn't a full integration. Hires can still read an Uptime Kuma status page you publish: add Uptime Kuma from Add a tool and follow the steps on its card.

1. Connect it in Roster

Open Integrations → Tools → Add a tool, search for Gatus and choose it.
How Roster signs in:
- No sign-in, if Gatus is only reachable inside your network;
- Username and password, if Gatus has security.basic set (or a proxy in front asks for them);
- Bearer token, if a proxy in front wants one.
Gatus's OIDC sign-in works in a browser only; put Basic or a proxy token in front for Roster.
Gatus address: the address you open Gatus's dashboard at.
Click Connect.

Roster has to be able to reach Gatus. If it's only on your own network, run Roster there or open a route to it.

2. Give hires access

On the hire's Tools tab, click Give access on Gatus. Read only and read and write are the same here: hires only read.

Endpoints: endpoint names, keys (like core_api) or groups (like core), one per line. The hire only sees these. Leave it empty for every endpoint.

Watching for outages

A hire's responsibility can watch Gatus: it's woken when an endpoint goes down, with the condition that failed, and again when it comes back up. Checking costs nothing when nothing changed.

If something goes wrong

"Couldn't reach it": Roster can't get to the address. Check it from where Roster runs.
"Didn't accept the connection's credential": the username or password is wrong.
"Couldn't find that": the endpoint key is wrong; list_endpoints shows each one's key.

Tools and permissions reference

This reference is built from the same definitions Roster uses to connect Gatus and give hires access. It updates with each release.

Authentication and requested permissions

The account or app you connect sets the outer limit. Each hire's access can narrow it further. Connecting a tool gives it to no hire until you give access on that hire's Tools tab.

User name and password or key pair

The user from Gatus's security.basic configuration.

For: How Roster signs in: Username and password (Basic).

API key or access token

Uses the Bearer token field. The credential stays in Roster.

For: How Roster signs in: Bearer token.

No sign-in

Connecting without a sign-in credential is supported when the service allows it.

No fixed permission list is declared for this connection. Review the sign-in consent screen, the account's roles, and the service's own documentation before connecting.

Connection fields

Gatus connection fields
Field	What to provide
How Roster signs in `signIn` Optional	Nothing, if Gatus is only reachable on your own network. Otherwise the username and password, or the token, your proxy or Gatus asks for. Choices: No sign-in (none); Username and password (Basic) (basic); Bearer token (token). Starts with: `none`.
Username `username` Required	The user from Gatus's security.basic configuration. Shown when `signIn: basic`.
Password `password` Required · sealed secret	Use the value for your account or connection. Shown when `signIn: basic`.
Bearer token `token` Required · sealed secret	Use the value for your account or connection. Shown when `signIn: token`.
Gatus address `url` Required	The address you open Gatus's dashboard at.

Per-hire limits

Read-only hires receive only actions that read. Read-and-write access also allows actions that change things, where the connection itself permits them. An empty resource allowlist usually means everything the connected account can reach; each field below explains its meaning.

Gatus per-hire limits
Field	What to provide
Endpoints `endpoints` Optional	Endpoint names, keys or groups, one per line. Leave empty for every endpoint.

Actions

2 actions: 2 only read and 0 change something. A read action may still need approval when your workspace or hire is set to ask. A locked approval requirement always applies.

Find an actionAccess

2 of 2 actions. Open an action for its arguments and full input schema.

list_endpointsRead only

Every endpoint Gatus checks, up or down, with its last check and why it failed. Down ones first.

Approval: Uses your workspace and hire approval settings.

Arguments for list_endpoints
Argument	Type	Details
`only_down`Optional	boolean	See input schema below.Default: `false`
`group`Optional	string	See input schema below.

Full input schema (JSON)

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "only_down": {
      "default": false,
      "type": "boolean"
    },
    "group": {
      "type": "string",
      "maxLength": 200
    }
  }
}

get_endpointRead only

One endpoint's uptime (last hour, day, week and 30 days), average response time, recent checks and when it went up or down.

Approval: Uses your workspace and hire approval settings.

Arguments for get_endpoint
Argument	Type	Details
`endpoint`Required	string	the endpoint's key, from list_endpoints, e.g. core_api

Full input schema (JSON)

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "endpoint": {
      "type": "string",
      "minLength": 1,
      "description": "the endpoint's key, from list_endpoints, e.g. core_api"
    }
  },
  "required": [
    "endpoint"
  ]
}

Watches and incoming events

This integration supports a responsibility that watches for changes. The guide above explains what it checks and how to limit it.
No incoming webhook handler is declared for this integration.

Limits and troubleshooting

Permission errors: check both the connected account's rights and the hire's resource and read/write limits.
Expired or revoked access: reconnect or replace the key on the connection.
Rate limits and unavailable services can interrupt work. The hire's timecard records the outcome.
The action schema describes accepted inputs. It does not grant additional access or bypass approvals.

Service documentation · Integration source reference

1. Connect it in RosterCopy Anchor Link

2. Give hires accessCopy Anchor Link

If something goes wrongCopy Anchor Link