> ## Documentation Index
> Fetch the complete documentation index at: https://kb.mspprocess.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Example: build an uptime monitor
> Check websites and portals every five minutes, email your service desk when one goes down or recovers, and show their status in an internal app.
Check a list of URLs every five minutes, email your service desk when one goes down or recovers, and show every service's status on an internal app page. It's a trimmed-down version of the uptime monitor in our own test organisation.
Build an uptime monitor: the database, the four workflows, the Status page, the live app and the schedule (1:25).
The full uptime monitor in our test organisation. The page you build here shows the same services in a simpler table.
You need a PostgreSQL database that Triggr can reach over the internet, with [Triggr's IP addresses](https://kb.mspprocess.com/security/ip-allowlist.md) allowed through its firewall.
## How it works
```mermaid theme={null}
flowchart TD
cron(["Cron, every 5 minutes"]) --> dispatch["Uptime - Dispatch Checks"]
button(["Check now on the page"]) -- "triggr.runWorkflow" --> dispatch
dispatch -- "one run per monitor" --> check["Uptime - Check Monitor"]
check -- "waits for" --> probe["Uptime - Probe Endpoint"]
probe -- "GET" --> site(("Monitored URL"))
check -- "saves the result" --> db[("Your PostgreSQL database")]
check -- "went down or recovered" --> email(["Email to your service desk"])
page(["The page loads"]) -- "webhook with ?await=true" --> status["Uptime - Status"]
status -- "reads" --> db
```
Dispatch Checks reads the monitors from your database and starts Check Monitor for each one without waiting. Check Monitor runs Probe Endpoint and waits for its answer: a site that doesn't answer at all fails only the probe's run, recorded as No response. It then saves the result, marks the monitor down after two failures in a row and emails when it goes down or comes back. The page can't read your database, so it calls Status through its webhook, and its Check now button starts a sweep with [`triggr.runWorkflow`](https://kb.mspprocess.com/studio/internal-apps/sdk#run-a-workflow).
## Build it
**1. Create the tables**
In your database's own SQL editor, run this, with one `uptime_monitors` row per site to watch.
```sql theme={null}
CREATE TABLE uptime_monitors (
id serial PRIMARY KEY,
name text NOT NULL,
url text NOT NULL,
status text NOT NULL DEFAULT 'unknown',
failures int NOT NULL DEFAULT 0,
last_checked_at timestamptz,
last_error text NOT NULL DEFAULT ''
);
CREATE TABLE uptime_checks (
monitor_id int NOT NULL REFERENCES uptime_monitors (id) ON DELETE CASCADE,
checked_at timestamptz NOT NULL DEFAULT now(),
ok boolean NOT NULL
);
CREATE INDEX ON uptime_checks (monitor_id, checked_at);
INSERT INTO uptime_monitors (name, url) VALUES
('Client portal', 'https://www.example.com'),
('Status page', 'https://status.example.org');
```
**2. Connect the database**
In Data > Databases, click **New Connection > Connection String**, paste your connection string and click Create Connection, then click Test Connection on its row (see [Databases](https://kb.mspprocess.com/studio/data/databases.md)).
**3. Import Uptime - Probe Endpoint**
In Workflows, click **Import Workflow**, paste this and click Import Workflow. It opens in the designer: click Save.
```json Uptime - Probe Endpoint theme={null}
{
"id": "set-on-import",
"name": "Uptime - Probe Endpoint",
"steps": [
{"id": "trigger-1", "type": "trigger", "label": "Trigger", "data": {"triggers": []}, "next": ["request"]},
{"id": "request", "type": "http_request", "label": "Request", "data": {"method": "GET", "url": "{{ ctx.params.url }}", "bodyType": "none", "allowNon2xxStatus": true, "allowInsecureTLS": false}, "next": ["finish"]},
{"id": "finish", "type": "finish_workflow", "label": "Finish Workflow", "data": {"outcome": "success", "comment": "{{ ctx.steps['Request'].status }}"}, "next": []}
],
"triggers": [],
"metadata": { "rootNodes": ["trigger-1"] }
}
```
Click Request to see its settings: Allow Non-2xx Status is on, so an error page still counts as an answer, and Finish Workflow returns the HTTP status as its Comment.
**4. Import Uptime - Check Monitor**
Import this the same way.
```json Uptime - Check Monitor theme={null}
{
"id": "set-on-import",
"name": "Uptime - Check Monitor",
"steps": [
{"id": "trigger-1", "type": "trigger", "label": "Trigger", "data": {"triggers": []}, "next": ["probe"]},
{"id": "probe", "type": "trigger_workflow", "label": "Probe", "data": {"workflow": "", "awaitCompletion": true, "params": "{ \"url\": {{ ctx.params.url | json }} }"}, "next": ["evaluate"]},
{"id": "evaluate", "type": "code", "label": "Evaluate", "data": {"javascript": "// A failed probe run means no response: DNS, refused, TLS error or the 30-second timeout.\nvar m = ctx.params;\nvar probe = ctx.steps['Probe'];\nvar code = probe.status === 'completed' ? Number(probe.finishNodeOutput.comment) : 0;\nvar ok = code >= 200 && code < 400;\n\n// Two failures in a row before it counts as down, so one blip doesn't page anyone.\nvar failures = ok ? 0 : Number(m.failures) + 1;\nvar status = ok ? 'up' : (failures >= 2 ? 'down' : m.status);\nvar error = ok ? '' : (code ? 'HTTP ' + code : 'No response');\n\nvar alert = 'none';\nif (status === 'down' && m.status !== 'down') alert = 'down';\nif (status === 'up' && m.status === 'down') alert = 'up';\n\nfunction q(s) { return \"'\" + String(s).replace(/'/g, \"''\") + \"'\"; }\nvar id = parseInt(m.id, 10);\n\nreturn {\n alert: alert,\n error: error,\n sql: 'WITH c AS (INSERT INTO uptime_checks (monitor_id, ok) VALUES (' + id + ', ' + ok + ')) ' +\n 'UPDATE uptime_monitors SET status = ' + q(status) + ', failures = ' + failures +\n ', last_checked_at = now(), last_error = ' + q(error) + ' WHERE id = ' + id\n};"}, "next": ["save-result"]},
{"id": "save-result", "type": "execute_sql", "label": "Save Result", "data": {"database": "", "sql": "{{ ctx.steps['Evaluate'].sql }}"}, "next": ["needs-alert"]},
{"id": "needs-alert", "type": "condition", "label": "Needs Alert", "data": {"conditionLanguage": "javascript", "conditions": [{"id": "down", "label": "Went down", "condition": "ctx.steps['Evaluate'].alert === 'down'"}, {"id": "up", "label": "Recovered", "condition": "ctx.steps['Evaluate'].alert === 'up'"}], "defaultLabel": "No change"}, "next": ["down-alert:down", "recovery-alert:up", "finish:default"]},
{"id": "down-alert", "type": "send_email", "label": "Down Alert", "data": {"to": "servicedesk@yourmsp.com", "subject": "DOWN: {{ ctx.params.name }}", "body": "{{ ctx.params.url }} has failed two checks in a row: {{ ctx.steps['Evaluate'].error }}."}, "next": ["finish"]},
{"id": "recovery-alert", "type": "send_email", "label": "Recovery Alert", "data": {"to": "servicedesk@yourmsp.com", "subject": "RECOVERED: {{ ctx.params.name }}", "body": "{{ ctx.params.url }} is responding again."}, "next": ["finish"]},
{"id": "finish", "type": "finish_workflow", "label": "Finish Workflow", "data": {"outcome": "success", "comment": ""}, "next": []}
],
"triggers": [],
"metadata": { "rootNodes": ["trigger-1"] }
}
```
Uptime - Check Monitor after import.
Click **Probe** and choose Uptime - Probe Endpoint as its Workflow, click Save Result and choose your database, change To on Down Alert and Recovery Alert to your service desk's address, then click Save.
Evaluate counts a status from 200 to 399 as up and the second failure in a row as down; Needs Alert only emails on a change. To alert on the first failure, change `failures >= 2` to `failures >= 1` in Evaluate.
**5. Import Uptime - Dispatch Checks**
Import this.
```json Uptime - Dispatch Checks theme={null}
{
"id": "set-on-import",
"name": "Uptime - Dispatch Checks",
"steps": [
{"id": "trigger-1", "type": "trigger", "label": "Trigger", "data": {"triggers": []}, "next": ["find-monitors"]},
{"id": "find-monitors", "type": "execute_sql", "label": "Find Monitors", "data": {"database": "", "sql": "SELECT id, name, url, status, failures FROM uptime_monitors ORDER BY id"}, "next": ["each-monitor"]},
{"id": "each-monitor", "type": "for_loop", "label": "Each Monitor", "data": {"expression": "ctx.steps['Find Monitors'].data", "variableName": "monitor"}, "next": ["check:body", "finish:complete"]},
{"id": "check", "type": "trigger_workflow", "label": "Check", "data": {"workflow": "", "awaitCompletion": false, "params": "{{ ctx.monitor | json }}"}, "next": ["end-loop"]},
{"id": "end-loop", "type": "end_for_loop", "label": "End For Loop", "data": {}, "next": []},
{"id": "finish", "type": "finish_workflow", "label": "Finish Workflow", "data": {"outcome": "success", "comment": ""}, "next": []}
],
"triggers": [],
"metadata": { "rootNodes": ["trigger-1"] }
}
```
Uptime - Dispatch Checks after import.
Click **Find Monitors** and choose your database, click Check and choose Uptime - Check Monitor as its Workflow, then click Save. You'll add its schedule once you've tested it.
**6. Import Uptime - Status**
Import this, click **Load Status**, choose your database and click Save. Its Trigger already holds a Webhook trigger.
```json Uptime - Status theme={null}
{
"id": "set-on-import",
"name": "Uptime - Status",
"steps": [
{"id": "trigger-1", "type": "trigger", "label": "Trigger", "data": {"triggers": [{"id": "trigger-webhook", "type": "webhook", "formId": "", "chron": "", "webhookEndpoint": null}]}, "next": ["load-status"]},
{"id": "load-status", "type": "execute_sql", "label": "Load Status", "data": {"database": "", "sql": "SELECT COALESCE(json_agg(json_build_object(\n 'name', m.name,\n 'status', m.status,\n 'lastCheckedAt', m.last_checked_at,\n 'lastError', m.last_error,\n 'uptime', (SELECT round(100.0 * count(*) FILTER (WHERE c.ok) / NULLIF(count(*), 0), 2)\n FROM uptime_checks c\n WHERE c.monitor_id = m.id AND c.checked_at > now() - interval '30 days')\n) ORDER BY m.name), '[]')::text AS monitors\nFROM uptime_monitors m"}, "next": ["finish"]},
{"id": "finish", "type": "finish_workflow", "label": "Finish Workflow", "data": {"outcome": "success", "comment": "{{ ctx.steps['Load Status'].data[0].monitors }}"}, "next": []}
],
"triggers": [{"id": "trigger-webhook", "type": "webhook", "formId": "", "chron": "", "webhookEndpoint": null}],
"metadata": { "rootNodes": ["trigger-1"] }
}
```
It returns each monitor's name, status, 30-day uptime, last check and last error as JSON, without the URLs: anyone with a webhook's URL can run it and read what it returns.
**7. Add the app page**
In Internal Apps, click **New App**, name it `Uptime` and click Create App. Click Design on its row, click Add Page, name it `Status` and click Create Page.
Paste this page and replace `STATUS_WORKFLOW_ID` and `DISPATCH_WORKFLOW_ID` with the IDs of Uptime - Status and Uptime - Dispatch Checks, from each workflow's address in Studio (`app.triggr-app.com/workflows//design`). Click Save, then **Preview**.
```html Status page theme={null}
Loading…
| Service | Status | Uptime (30 days) | Last checked | Last error |
|---|
```
Preview loads the table from Uptime - Status.
**8. Let the page start sweeps**
Click **Settings**, leave Authentication Type as Internal, tick Uptime - Dispatch Checks under Workflows pages can run and click Save Settings.
Your team opens the live app at `https://app.triggr-app.com/telescope/apps//` with their staff sign-in (**Support > Copy Org ID** in the top bar gives the first ID; the second is in the designer's address bar). Open on Internal Apps shows the page without the SDK, so Check now only works on that link.
## Test it
**1. Probe a URL**
Open Uptime - Probe Endpoint, click **Manual Trigger**, enter `{ "url": "https://www.example.com" }` and click Trigger Workflow. In the run, Finish Workflow's output has `comment: "200"`.
**2. Check one monitor**
Open Uptime - Check Monitor and trigger it with the first monitor's row:
```json theme={null}
{ "id": "1", "name": "Client portal", "url": "https://www.example.com", "status": "unknown", "failures": "0" }
```
The run reaches Finish Workflow without sending an email, and that monitor's `status` in your database is now `up`.
**3. Run a sweep from the app**
Open the live app link from the last build step and click Check now. The page refreshes 30 seconds later, and Uptime - Check Monitor's Runs has one run per monitor.
**4. Test an alert**
Add a monitor that can't answer, click **Check now**, wait for the page to refresh and click it again. The second failure marks Alert test down and emails DOWN: Alert test.
```sql theme={null}
INSERT INTO uptime_monitors (name, url) VALUES ('Alert test', 'https://down.example.invalid');
```
Then delete it: `DELETE FROM uptime_monitors WHERE name = 'Alert test';`
## Go live
Open Uptime - Dispatch Checks, click Trigger, then **Add Trigger**, set Trigger Type to Cron, enter `*/5 * * * *` and click Save.
Check all four workflows show Active on Workflows (imports start Active). Add a row to `uptime_monitors` for each site to watch, and the next sweep picks it up.
## FAQ
> [accordion] Can it check more often than every five minutes?
>
> No. [Scheduled runs](https://kb.mspprocess.com/studio/workflows/triggers.md#cron) are at least five minutes apart.
> [accordion] Why are there so many runs?
>
> Each sweep is one Uptime - Dispatch Checks run plus a check and a probe per monitor (21 runs for 10 monitors), and the page adds an Uptime - Status run each time it loads.
> [accordion] How do I stop uptime\_checks growing forever?
>
> Add a workflow with a Cron trigger such as `15 3 * * *` and an Execute SQL step that runs `DELETE FROM uptime_checks WHERE checked_at < now() - interval '90 days'`.
> [accordion] Can it check sites on a client's internal network?
>
> No. Requests come from Triggr's servers, so each URL must be reachable from the internet; a site with an allow list needs [Triggr's IP addresses](https://kb.mspprocess.com/security/ip-allowlist.md).
> [accordion] Can I share the page with clients?
>
> Not as built: every client would see every monitor. Keep it Internal, or build a page per client with its own Status workflow.
## Troubleshooting
> [accordion] Test Connection fails, and my password has special characters
>
> Click **Edit** on the connection and type the password into Password; a connection string needs `@`, `:` and `/` encoded.
> [accordion] Execute SQL fails with “invalid SQL query”
>
> Triggr checks each query with `EXPLAIN` first, so statements such as `CREATE TABLE` fail. Create tables in your database's own SQL editor.
> [accordion] A run fails with “trigger node … not found” or “no trigger node found”
>
> The pasted JSON didn't start with a top-level `"id"`. Import the JSON from this page again.
> [accordion] The page shows “Status request failed (HTTP 404)” or Check now shows “this app is not allowed to run that workflow”
>
> Check the two IDs in the page, that Uptime - Status is saved with its Webhook trigger, and that Uptime - Dispatch Checks is ticked under Workflows pages can run.
> [accordion] Check now shows “triggr is not defined”
>
> You opened the page with Open. Use the live app link from the last build step.
> [accordion] A monitor stays unknown
>
> It hasn't been checked yet, or has failed once and not been up since; its `last_error` column says why.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.