Everything you need to go from a fresh account to a monitor that pages the right person at the right time, and a public status page to share. It takes about ten minutes.
Head to the dashboard and choose Create one on the sign-in screen.
Enter your email and a password of at least eight characters. A display name is optional. Complete the verification challenge and submit.
We send a confirmation link to your address, and a screen reminds you to check your inbox. Click the link to activate the account. You can't sign in until your email is confirmed.
Back on the sign-in screen, enter your details. We email you a six-digit code for two-factor authentication; enter it to finish signing in. The field submits as soon as the sixth digit lands, and the code expires after ten minutes.
A monitor is one thing you watch, plus the escalation you draw around it. Each monitor is a single flow on its own canvas. Start here: connections and notify steps live inside a monitor's editor, so you make the monitor first.
Choose New monitor in the header, give it a name like Checkout API, and create it. You're dropped onto the canvas with one Monitor block already placed.
The check settings open automatically for a new monitor, or one that hasn't been configured yet. You can reopen them any time by double-clicking the Monitor block.
Pick how Hesklo probes the target, from the four types below.
example.com or an address like 192.0.2.1.host:port accepts a connection, for example a database at db.example.com:5432.systemctl is-active), disk usage, memory usage or load average. Disk, memory and load take a threshold and go down when it's exceeded; the service check is down when the unit isn't active. You pick the check from a list rather than typing a command, so there's nothing to inject./home/hesklo/.ssh/authorized_keys prefix the public key with restrict so it can't open shells, forward ports or allocate a terminal. The account only needs read access for the disk, memory and load checks, plus permission to run systemctl is-active for the service check. Point the monitor's SSH user at this account, not root.Then set the timing:
Choose Apply to save the check. Hesklo runs one check straight away so the status reflects your new settings without waiting for the next interval. The Monitor block now shows a summary, and its output ports become meaningful: a red down port, an amber warning port and a green up port.
Hesklo (+https://hesklo.com), so Hesklo's traffic is easy to spot in your access logs and simple to allowlist if a firewall or WAF sits in front of the target. (The public URL-check tool uses a separate Hesklo-Check/1.0 agent.)Beyond up and down, a monitor can raise a warning while it's still healthy, so you hear about a problem that's coming rather than one that's already here. The check settings have a Warn me when section with two conditions you can switch on:
An active warning lights up the Monitor's amber warning port, separately from down and up, so you can route a gentle heads-up somewhere different from a full outage page. See Draw a flow for how to wire it.
A connection is an external place an alert can go, such as a Slack channel or a PagerDuty service. You set one up once, then any notify step in any flow can point at it. Connections live in the right-hand sidebar of the monitor editor.
Each external notify module only becomes available once a matching connection exists, so add the connections you need before you wire up the flow. Email is the exception — it's built in and always ready (see the note below).
In the editor's right sidebar, choose + Add connection.
Choose from Slack, Discord, Microsoft Teams, Google Chat, Telegram, Pushover, ntfy, SMS, a Twilio phone call, PagerDuty, Jira, GitHub or a generic Webhook. Give it a clear name like ops-slack so it's easy to recognise later.
Each type asks for what it needs, for example an incoming webhook URL for Slack, a bot token and chat ID for Telegram, your Twilio credentials for SMS or a phone call, a repository for GitHub, or an Events API routing key for PagerDuty. Credentials such as tokens and API keys are encrypted at rest.
Once the connection is saved, use Send test to confirm the alert arrives before you rely on it.
A flow is what happens when the monitor changes state. You build it by dragging modules from the left palette onto the canvas and wiring them together. The flow runs from the Monitor's three ports: the down port drives your escalation, the amber warning port carries proactive heads-ups (cert expiry, slow response, page content changed), and the up port sends the all-clear.
From the left palette, drag a logic, notify or action block onto the canvas. External notify blocks appear once you have a matching connection; Email is always available.
Drag from an output port (the dot on the right of a block, or the down/warning/up ports on the Monitor) to the input port on the left of the next block. A dashed line follows your cursor as you drag, and releasing anywhere on the target block completes the link. Blocks that branch have more than one output port: the Monitor has three (down, warning and up), and a condition check has two (pass and fail).
Double-click a block, or right-click it and choose Edit, to open its settings. Notify blocks let you choose where the alert goes — a connection, or for Email a recipient from your account and team — and the message, with placeholders like {flow}, {state}, {detail} and {duration}. If you have just one connection of the right type, a new notify block picks it automatically.
Right-click a block for Unlink, which clears its connections but keeps the block, or Remove, which deletes it. The Monitor block can't be deleted; it's the root of the flow.
A common first flow: from the Monitor's down port, add a Wait of five minutes, then a Slack notify. From the up port, add an Email notify. The result: if something is down for five minutes you get a Slack page, and when it recovers you get an email all-clear. Nothing fires for a blip that clears inside five minutes.
The same building blocks compose into richer policies. A Repeat alert after your first page keeps paging every few minutes until someone fixes the problem. A Condition check probes a second endpoint mid-flow and routes on the result, so you can ask "the API is down, but is the database also down?" and page a different team for each answer. An HTTP action can even try to fix things first: call an endpoint to restart a service, then use a condition check to re-probe, and only page a human if it's still down. And since every HTTPS monitor tracks its certificate, an If / else set to SSL certificate expires within N days can warn you before a cert runs out instead of after.
The Monitor's amber warning port fires while the monitor is still healthy but a condition you set is tripping — an SSL certificate nearing expiry, a response time over your threshold, or the page's content changing (see Create a monitor for turning these on). Wire a notify off the warning port to get a low-key heads-up that never mixes with your outage pages: for example, post cert-renewal reminders to a Slack channel instead of paging on-call.
When you've switched on more than one warning, put an If / else set to Warning is of a specific type after the warning port to split them: send certificate warnings one way, slow-response warnings another, and content-change warnings somewhere else again. Warnings alert once while active and clear themselves when the condition passes again, just like an incident resolving.
An email alert can ask the recipient to acknowledge that they're handling the incident. Turn on Ask for acknowledgement in an email notify's settings (it shows when the email step sits on a down path) and the email includes an Acknowledge button. Clicking it marks the incident acknowledged.
Pair that with an If / else set to Not acknowledged in N minutes to build an escalation that only fires when nobody responds. For example: email the on-call engineer with acknowledgement on, then an If / else for "not acknowledged in 15 minutes" whose true path pages a second person. If the first engineer acknowledges in time, the second page never happens. Acknowledgement resets automatically when the monitor recovers, so each new outage starts fresh. Once acknowledged, the overview and the mobile view show that someone has picked the incident up.
A small set of blocks combines into any policy. Logic blocks shape the flow, notify blocks send the alert, and action blocks do something about the problem.
With the check set up and the flow drawn, put it to work.
Open a monitor and switch to its History tab for the full picture of that one check: a 30-day uptime chart, a 24-hour response-time graph, its incident list and a recent event log, all alongside a sidebar of vital signs like current state, uptime and certificate status. The event log also captures notes left by Log blocks and the calls made by HTTP actions, so the timeline shows everything the flow did. Hover any chart for the exact figure behind a point.
Back on the Overview you'll see this monitor alongside the rest: status, 30-day uptime, certificate expiry and check interval, one row each. A second Incidents tab lists recent outages across all your monitors, with their start, duration and cause. Click any monitor row to open its flow again.
A status page is a public, read-only page where anyone can check whether your services are up, no account required. It shows an overall banner, your chosen monitors with their 30-day uptime, and recent incidents. It's entirely opt-in: nothing is public until you set it up, and it's available on paid plans.
Open the account menu, choose the Status page tab, and set a page title and a subdomain. Your page goes live at yourname.status.hesklo.com. The page only publishes once both a title and a subdomain are set; clearing them takes it down again.
Open a monitor's Settings and turn on Show on status page. Only the monitors you switch on are shown; everything else, including the incidents of private monitors, stays hidden.
That's it. Anyone with the URL sees a live, branded status page that updates as your monitors do.
Every status page also publishes its incidents as an RSS feed at /rss on the same address, for example yourname.status.hesklo.com/rss. There's a small RSS icon next to the incident list linking to it. Anyone can subscribe in their feed reader and get new incidents without checking the page. Like the page itself, the feed only ever includes the monitors you've made public.
Once your page is published you can serve it from your own domain, like status.yourcompany.com, instead of the Hesklo subdomain. Add the domain in the Custom domain field of the Status page tab and save it together with the rest of your page settings.
At your DNS provider, point your domain at status.hesklo.com with a CNAME record. For example, a record for status.yourcompany.com whose target is status.hesklo.com.
Enter the same domain in the Custom domain field and save. The page publishes first, then the domain attaches to it, so make sure your title and subdomain are set too.
That's the whole loop. Build a monitor, add the connections its alerts need, draw what happens when it breaks, let it run, and publish a page so everyone can see the state at a glance.
On the Team and Business plans you can invite other people to work on the same account, so being on call isn't one person's job. Everyone signs in as themselves but shares the same monitors, connections and history, so there's nothing to set up twice. Team members also become selectable recipients on the Email notify, so a flow can page a specific teammate.
From the account menu in the top right, choose Team. It shows how many seats you've used, out of the 10 the Team plan includes or the 25 on Business.
Enter the person's name and email, choose their access level, and pick Send invite. They receive an email with a link to join. The address can't already belong to another Hesklo account.
The link opens a short screen where they set a password and are signed straight in. Until they do, they appear as pending in your member list.
Change someone's access level or remove them at any time from the member list. Removing a member revokes their access immediately and frees the seat; their login is closed, while every monitor, connection and all history stays with the account.
Once more than one person is on the account, an on-call schedule decides who an email alert goes to, rather than every alert landing on the same fixed address. You paint a week of shifts across your team, and an Email step set to follow the rota pages whoever is on duty at the moment it fires. It's part of the Team and Business plans, alongside team members.
The schedule is a repeating week, not a calendar: it has no end date and no exceptions, which is what keeps it to one screen and one save. The same week runs every week until you change it.
Choose On-call in the top right, next to Help. The button only appears on plans that include a rota.
The rail on the left lists you and every team member who has accepted their invite, each with their own colour. Click a person to pick them up, like a brush. Someone has to accept their invite before they can be put on call, so pending invites aren't listed.
Drag across the week grid to fill in the hours that person covers. Quick fill does the common shapes in one click — weekdays 09:00–17:00, weeknights 17:00–09:00, or the whole week — and the eraser clears hours back to nobody. Only one person can be on call at a time, so painting over someone else's hours takes them over.
Set the Timezone at the top of the planner. The week's hours are read in that zone, so a rota written as 09:00–17:00 in Amsterdam keeps meaning that when the clocks change. A schedule you've never saved starts in your own browser's timezone.
Choose Save schedule. The rail shows who is on call now at a glance, and the footer tells you how much of the week is covered.
The schedule on its own doesn't change where alerts go — a flow has to ask for it. Open any Email step in a flow and turn on Use the on-call schedule. From then on, that step sends to whoever is on call at the moment it fires, in place of the recipient chosen in the step. Everything else about the step, including the message, subject and the Acknowledge link, works exactly as before.
A gap in the week is a fallback, not an error. If nothing covers the moment an alert fires, the Email step simply sends to its own chosen recipient instead. The same fallback covers every other loose end: no schedule saved yet, or the person on call has since left the team. An alert is never dropped because of the rota — the worst case is that it goes to the fixed address you already picked.
Open the dashboard on a phone and you get a mobile view built for checking status on the go. It's read-only by design: a quick way to see if everything is healthy without the full editor.
Everything you do in the dashboard, your own scripts can do too. The API lets you read monitors, status, uptime and incidents, and create, edit and run monitors, from a deploy pipeline, a terminal or anything else that speaks HTTP. It's available on any paid plan.
From the account menu in the top right, choose API. Only the account owner can manage keys.
Choose New key, give it a name you'll recognise later like Deploy script, and pick its access level. Read-only can view monitors, status and history; read & write can also create, edit, run and delete them.
The key is shown once, at the moment you create it. Only a hash of it is stored, so it can't be shown again — if you lose it, revoke it and create another. You can hold up to ten keys at a time.
Send the key as a bearer token. Every endpoint lives under https://dashboard.hesklo.com/api/v1 and is scoped to your account, so there's no account id to pass.
Responses are JSON, and so are errors, in the shape {"error": "..."}. A 401 means the key is wrong or revoked, 402 that your plan doesn't include the API, and 403 that you used a read-only key for a write. Each key is limited to 120 requests a minute.
GET /monitors — every monitor, including its full flow. POST the same path to create or update one, and DELETE /monitors?id= to remove it.POST /monitors/run?id= — probe a target immediately and get the full result back, ignoring the schedule.GET /status — current up or down state of every monitor, with when it started and the last error.GET /overview — the same rollup as the Overview screen: state, target, uptime and check interval, one row per monitor.GET /incidents — recent incidents across the account, with their start, duration and cause.GET /monitor?id=&range= — uptime and response-time detail for one monitor. range accepts 24h, 7d, 30d or 90d, clamped to your plan's history.GET /events?id= — the event log for one monitor. Add filter=alerts, notes or checks to narrow it.GET /connections — your configured connections. Credentials are never returned, only which fields are set.Hesklo speaks the Model Context Protocol, an open standard for giving AI tools access to live data. Any assistant, chat app or AI-enabled editor that supports MCP can read your monitoring: ask "is production healthy?" or "what went down last night and for how long?" and it answers from your account rather than guessing.
There's nothing to install. Hesklo hosts the server at https://dashboard.hesklo.com/mcp; you point your assistant at that address and give it an API key. The key is what scopes it, so an assistant can reach exactly what a script holding that key could reach, and nothing more.
Follow the steps in Use the API. A read-only key covers every question the assistant can answer; you only need read & write if you want it to run checks or pause monitors for you.
Wherever you're configuring it, a client needs the same two things: the URL https://dashboard.hesklo.com/mcp, and an Authorization header carrying your key. Most clients keep a JSON config file with a section like this:
Some clients offer a form in their settings instead, with fields for the URL and headers, and some have a command that writes the config for you. The field names vary a little between clients — a few use remote or streamable-http where this example says http — so check your client's own MCP documentation for the exact shape.
Start a conversation and ask about your monitors — "is everything up?", "what went down last night?" The assistant calls the tools below as it needs them.
You can name a monitor the way you'd say it out loud — checkout API works as well as its id. If a name matches more than one monitor, the assistant is told which ones rather than guessing at the wrong one.
Add a monitor, wire it up, and let Hesklo handle the 3 a.m. part.