When you create a monitor, you choose which HTTP method PulseAPI uses for each check. This article explains the available methods and when to use each one for monitoring.
The Methods
GET
Use for: Most health check and status endpoints.
GET retrieves a resource without modifying it. It's the right choice for any endpoint designed to be called repeatedly without side effects — health checks, status pages, API root endpoints.
GET /health → 200 OK
GET /api/v1/status → 200 OK
If you're unsure which method to use, start with GET.
POST
Use for: Endpoints that require a POST to respond.
Some APIs only accept POST requests even for status checks. Use POST when:
- The endpoint returns an error for GET requests
- The endpoint requires a request body (e.g., a JSON payload) to produce a valid response
- You're monitoring a form submission or API action endpoint
When using POST, configure a request body if the endpoint requires one. See Adding a Request Body to a Monitor.
HEAD
Use for: Lightweight reachability checks when you don't need the response body.
HEAD behaves like GET but the server returns only headers, not the response body. This is useful for:
- Large assets or files where downloading the body would be slow
- Simple "is the server reachable" checks without caring about content
- Reducing bandwidth if you're monitoring many endpoints at high frequency
Note: Some servers respond differently to HEAD vs GET. If you see unexpected failures with HEAD, switch to GET.
PUT / PATCH / DELETE
Use for: Monitoring write endpoints — with caution.
PUT, PATCH, and DELETE can modify or delete data on your server. Only use these if:
- The endpoint is specifically designed to be idempotent (safe to call repeatedly)
- You have a test/stub endpoint that accepts these methods without causing side effects
- You're monitoring a specific write operation as part of an integration test
Warning: Using PUT, PATCH, or DELETE on production write endpoints will actually modify or delete data with every check. Be certain the endpoint handles this safely.
Summary
| Method |
When to Use |
| GET |
Default; health checks, status endpoints, read-only APIs |
| POST |
POST-only endpoints, endpoints requiring a request body |
| HEAD |
Reachability checks where body content doesn't matter |
| PUT / PATCH / DELETE |
Write endpoints — only if idempotent and safe to call repeatedly |
Related Articles
Still have questions? Contact support.
Related Articles
Creating a Monitor
This article explains how to add a new monitor (endpoint) to PulseAPI. After completing these steps, PulseAPI will begin checking the URL on your configured schedule and alert you if it goes down. Prerequisites: You must be a team Owner, Admin, or ...
Adding a Request Body to a Monitor
When you monitor a POST, PUT, or PATCH endpoint, you may need to send a request body for the endpoint to respond correctly. This article explains how to configure a request body on a monitor. When You Need a Request Body Most health check endpoints ...
Check Intervals Explained
The check interval is how often PulseAPI sends a request to your monitor. This article explains what intervals are available, how your plan affects them, and how to choose the right interval for each monitor. What Is a Check Interval? Every monitor ...
Authentication Options for Monitors
If the endpoint you want to monitor requires authentication, PulseAPI needs to send credentials with each check. This article explains the supported authentication methods and how to configure them. Option 1: Basic Authentication Basic auth sends a ...
Plans and Pricing Explained
PulseAPI offers four plans. This article describes what each plan includes so you can choose the right one for your team's needs. Plan Overview Free Starter Professional Team Price $0/month Paid Paid Paid Monitors 10 50 200 500 Team members 1 3 10 25 ...