Training

Some failures only show up when you act like a user: a login form that rejects valid credentials, a dashboard that loads empty, a checkout that returns an error after the cart. A plain HTTP check cannot see those.

In this video you create a JavaScript check in SolidPing. The script runs in a sandboxed engine, loads a login page, signs in with a test account, and asserts what the dashboard shows. You will see how to store the password as an encrypted secret, how to try the script with Run now, and how a failing step is reported in the result.

JavaScript checks run once per period in every region, open incidents like any other check, and notify your channels.

Describe what you want to watch in plain words and let SolidPing write the check.

In this video you use the AI engine: you write a one sentence description, review the contract of assertions it proposes, and watch it explore the page and test a script live. You save the result as a normal JavaScript check. After that, the script runs on the workers like any other check, with no AI call per run.

When the target changes its pages and the script breaks, SolidPing can repair it. A repair starts only when the script itself broke (it can no longer find a field or a page) on 3 runs in a row while the site still answers, so a real outage never triggers one. The AI rewrites the script against the same contract, and the new version must pass a verification run, reach no new host and still be able to report down. You choose the mode under When the script drifts: Propose a repair (the default) waits for your approval on the check's History page, Repair automatically applies it, resolves the incident on the next run and emails you the diff.

The feature needs an AI provider configured on the server. Without one, the button is hidden.

Cloud workers cannot reach a database on a private network, a VPN-only host or an air-gapped segment. Private locations solve that: you run a SolidPing agent inside your network, and it runs the checks for you.

In this video you create a private location, mint a one-shot enrollment token, start an agent, and run a check from it. The agent dials out over a WebSocket, so no inbound port is needed. It can only claim jobs and submit results, and secrets for private-only checks are encrypted to the agents' keys, so the server cannot decrypt them.

A TCP check on port 3389 only proves that a port is open. The RDP check performs the pre-authentication Remote Desktop handshake, so a valid answer proves that the service really parsed the request.

In this video you create an RDP check, run it, read the negotiated security protocol (TLS, NLA and so on) and the server certificate expiry, then stop the service to see the check go down and an incident open. No credentials are needed and nothing is logged in, so your Windows event logs are not filled with authentication failures.

RDP hosts are usually private: run the check from a worker or private agent that can reach them.

The VNC check speaks the real RFB protocol: it reads the banner, negotiates a version and lists the authentication methods the server offers. A server that offers no authentication is marked down by default, because an open desktop is almost always a mistake.

In this video you run a handshake only check, then add a password so the check logs in and reports the desktop name and size, and finally turn on the screenshot option to attach a picture of the desktop to the result.

During an outage, the worst place to look for context is five different messages in a channel. SolidPing keeps one Slack thread per incident.

In this video you connect Slack, attach a channel to a check, and watch an incident open as a message with an Acknowledge button. You acknowledge it from Slack, add a comment with the slash comment command, and see the recovery posted in the same thread. Comments written in the dashboard are posted as replies in the thread too.

An on-call schedule answers a simple question: who is responsible right now?

In this video you create a weekly rotation with a handoff time in your own timezone, add three people to the roster, see who is on call now and next, add an override to cover a shift, and publish the schedule as an iCal feed for your calendar. Handoffs follow the wall clock, so daylight saving time does not move your shifts.

Alerting someone is easy. Making sure someone answers is the hard part. An escalation policy is an ordered list of steps with delays, and each step can notify several targets at the same time: a user, an on-call schedule or a channel.

In this video you build a three step policy (the person on call, then a named person after ten minutes, then a team channel after twenty), attach it to a check, trigger an incident and read the timeline. Acknowledging the incident from the dashboard, Slack or Telegram cancels the pending steps.

A status page tells your customers what is happening so they stop asking you.

In this video you create a status page, organize it in sections, add components, and switch a section to automatic membership (all checks, by label or by group) so new checks appear without manual work. You then open the public page, see it react when a check fails, and post an incident update.

Note that automatic inclusion on a public page is a disclosure decision: only turn it on for sections you are happy to publish.

One database outage should not become four pages in the middle of the night.

In this video you declare dependency edges between checks. A hard edge says that the failure of a parent causes the failure of its children, so the child incidents still appear in the timeline but do not page anyone. A soft edge only records a correlation, and the incident still pages. You will see the effect when a database fails, how the rollup works even when the parent confirms last, and what happens when the parent recovers.

Up is not enough. Is it up enough? An SLO sets a target, for example 99.9 percent per month, and SolidPing tracks the error budget: how much failure you can still afford, how fast you are spending it, and when it will run out.

In this video you create an objective for a check, read the status card (attainment, budget consumed, remaining, status chip), understand the burn rate and projected exhaustion, and read the burn-down chart. Planned maintenance is excluded by default, and you can mail the numbers on a schedule as an uptime report.

Email is the one channel everybody already has.

In this video you add an email channel and attach it to a check. You see the incident email when a check fails and the resolved email when it recovers: two messages per incident, not one per failed probe. You see that an incident suppressed by a failing dependency sends nothing. Then you schedule a weekly uptime report and read the digest: availability compared with the previous period, incident summary and the state of your error budgets.