What a monitor can check
| Kind | What it checks | Options |
|---|---|---|
| Website or API | An http:// or https:// address: the answer, the certificate, and how fast it answers | The status codes to expect, words the page must contain, JSON paths with a value or "exists", request headers, a header filled from one of your stored secrets, and a warning 0 to 365 days before the certificate expires. A credential is never written into the address. |
| Port | That a TCP port accepts connections, such as db.internal:3306 | Host and port |
| Ping | That a host answers ICMP | 1 to 10 pings, and the packet loss that counts as a failure |
| DNS | A name's records | A, AAAA, CNAME, MX, TXT or NS, and up to 20 values to expect |
| Heartbeat | That a job checked in on time | An expected period and a grace period, or a cron schedule in a time zone |
Every monitor has an interval from 15 seconds to 60 minutes, a timeout shorter than that, a slow threshold in milliseconds, and how many failures (1 to 10) make it Down and how many successes bring it back Up. Its state is Up, Down, Pending (not enough results yet to say) or Paused (paused by you).
New monitor walks you through it: what to watch, from where, how, and who should know. Its last step runs the first check in front of you.
Where checks run, and the vote
- A public target is checked by BasePit's workers, in up to three places. The places are chosen from the monitor's id, so they stay the same across restarts.
- A private target, such as an address inside your network, is checked by your own hosts, which are already there.
- To check from exactly one machine, name it under More options.
The vote. Each place confirms a failure on its own, as a run of failed checks, before it says Down. Then the places vote. When one place sees a failure and the others do not, the monitor says so, for example "it looks down from one place only", and nobody is paged for a problem in one network.
Fail or error. A check that got a wrong answer, or no answer in time, is a fail. A check the node could not run at all, such as one whose resolver is down, is an error: a fact about that node, which never moves the monitor towards Down.
Heartbeats for jobs
A heartbeat is the one monitor nothing dials. Your job calls BasePit when it finishes:
0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://app.basepit.com/h/<TOKEN>- BasePit expects a call every period, allows the grace period on top, and then marks the job late, then down.
- On a schedule, BasePit expects the call at each time of a cron line in your time zone.
- Add
/startand/failto the URL to report those too. - The token is 32 random bytes, shown once and stored only as a hash. An unknown or revoked token gets an empty 404, so nothing can be probed. Regenerate replaces an exposed one at once.
Incidents
- A monitor that goes Down opens an incident, and resolves it when it comes back Up. Incidents are numbered per organisation.
- Each has a timeline, newest first, and updates you post. Acknowledging one quiets its messages until it resolves.
- Declare one by hand for something no monitor sees, such as a payment provider's outage or a slow mail queue, and resolve it yourself with an update.
- An incident that opened while its alerts were quiet says so.
Status pages
A status page is a public page for the people who use what you run: what is up, what is down, and what is planned.
- It shows only the components you put on it, and only the incidents you make public. Planned maintenance can be announced on it.
- Each page also serves
status.json, abadge.svgfor your README or site, andhistory.csv. - Pages are plain HTML with a strict content security policy, cached for 30 seconds.
- You can turn a page off, and preview it as its address shows it now.
Alert rules
A rule says what to watch and which channel to tell. Twelve kinds cover apps, hosts and monitors:
| About | Rules |
|---|---|
| Apps | An app that stops · a health check that fails · a container restarting again and again · fewer copies running than declared · a container out of memory |
| Hosts | A host that goes offline · CPU high for some minutes · memory high · disk high |
| Monitors | Down · slow · a certificate about to expire |
The other areas bring their own: Kubernetes (5), RHEL servers (4), Proxmox (4), Automation (1), and host insight (2: a failed service and a reboot wanted). A monitor rule has no timings of its own, because the monitor has already confirmed the outage before the rule hears of it.
An app that has never run does not page when it is created stopped, and a disabled app sends nothing. Alerts can also go to the team that owns the app, host or monitor.
Channels
| Channel | Sends |
|---|---|
| Slack | A message in a Slack channel, through an incoming webhook |
| An e-mail through your own mail server: its host and port, with its password kept sealed. Separately, any rule can also e-mail everyone in the team that owns what fired, when it fires and when it recovers. | |
| Telegram | A message from your Telegram bot |
| Webhook | A JSON post to your address, signed with an X-Basepit-Signature header so your receiver can prove it came from BasePit. Use it to pass alerts to any SMS or voice provider you already have. |
| SMS, WhatsApp, WhatsApp call, phone call | Sent by BasePit, from your first credit purchase on, a few credits per message. The number is verified first. A call plays a fixed recording that tells you something is wrong. |
Each paid channel shows its price before you save it: per message when something breaks, when it comes back, and every hour while it stays down, as you choose. A recovery is sent exactly when its outage was.
Quiet and maintenance
Quiet means "I switched this off on purpose; stop telling me." It holds back the messages and nothing else: checks continue, states stay true, and a held message is never charged.
- A quiet covers an app, a monitor or a host (and every app on it) for an hour, a day, a week, until a date up to 30 days away, or until you turn it back on.
- When a quiet ends on something still down, one message says so.
- Maintenance windows are planned quiets, once or weekly in their own time zone, over monitors, apps, hosts, tags or everything, and can be announced on a status page.
- A deploy quiets the app's alerts while it runs. Acknowledging an incident quiets it until it resolves.
- Everything quiet now, and what ended recently, is listed in one place under Alerts.
History
Every check is stored whole, and availability and response times are computed from those checks when you look, never added up along the way. So a figure on a screen can always be traced back to the checks that made it. A monitor's page also shows its last 90 days, day by day. How long history is kept depends on your account, and Billing states it.
Limits
- Status pages are served at BasePit's own address. Custom domains are not offered.
- Outside checks run from BasePit's workers. You cannot add a worker of your own; your hosts check private targets.
- Quiet holds messages, never checks: there is no way to stop a check except pausing the monitor.