Synthetic monitoring

Operations → Synthetic Monitoring (/gravity/operations/synthetic-monitoring) lets you define HTTP checks against your own endpoints - independent of whether a Sencai-provisioned instance or fleet agent is reporting in - so you know an endpoint is reachable even if nothing else in the platform would otherwise tell you.

Creating a check

A check has:

Field	Meaning
Name	A label for the check
URL	The endpoint to request
Method	GET, POST, or HEAD
Interval	How often the check should run, in seconds
Expected HTTP status	The status code that counts as passing (for example, 200)
Body contains (optional)	A substring the response body must include to pass
Enabled	Whether the check is active

Creating and deleting checks requires the Member role or higher.

Caution

Automatic execution of the checks you define here isn’t active in this environment today - checks are created and stored, but nothing currently runs them on your configured interval, so you shouldn’t expect results or failure alerts to appear yet. If uptime checking on your endpoints is something you need now, ask your account team.

A check is scoped to your active organization - switching organizations in the app switches which set of checks you see, the same as most other pages in this section.

Why define checks now anyway

Even with execution not active yet, it’s reasonable to define your checks today: the configuration (URL, method, expected status, interval) is what your account team needs to turn on real execution for you, and having it already recorded here means there’s nothing left to gather when that happens.

Reading results

Selecting a check from the table opens its Recent Results - each recorded run’s pass/fail status, response time, the HTTP status code returned, and any error message, with a timestamp. Once execution is active for your environment, this is where you’ll see history accumulate; an empty results list today reflects the state above, not a misconfigured check.

Locations and alerting on failure

Checks run from a single location today - there’s no per-check location selector in this screen. A failing check doesn’t currently generate its own dedicated alert or notification separate from what’s described above; treat this screen as an endpoint-status reference rather than an alerting channel for now.

Deleting a check

Deleting a check removes it from the list; any results already recorded for it stay in the database rather than being deleted along with it, though you won’t have a way to browse them back once the check itself is gone.

Synthetic checks vs. instance and agent monitoring

	Synthetic monitoring	Monitoring
Checks	An HTTP endpoint you specify	CPU/memory/disk on a Sencai-managed resource
Requires	Nothing Sencai-managed - any reachable URL	A provisioned instance or enrolled agent
Good for	”Is this endpoint up”, from the outside	”Is this resource healthy”, from the inside

Tip

Use both where it makes sense - synthetic monitoring catches a DNS, load balancer, or network problem in front of an instance that instance-level metrics alone wouldn’t show, since it tests the same path a real visitor would use.

What’s next

• Monitoring - metrics and alert thresholds for your provisioned instances and fleet agents
• Incidents - where correlated alert activity ends up once it exists
• Fleet: monitoring - the agent-side counterpart for enrolled servers
• Support - reach your account team about enabling active checking sooner