Hund offers a free-of-charge native monitoring solution to track your services without the need of a third party.
Watchdog
This watchdog will report the status of any given ICMP, HTTP, DNS, TCP, or UDP target. If there is a protocol you wish to see support for, let us know at support@hund.io!
General Options
Check Method
The method to use to check the target.
Target
The host the check will make calls to.
In the case of DNS, this is the domain/IP address that will be queried. IP addresses do not need to be converted to the z.y.x.w.in-addr.arpa format, as this will be done automatically. Of course, we accept both formats for DNS.
Regions
The regions you would like the target to be checked from. All regions are weighted equally when calculating the outcome of a check. Currently, a single check can use up to 8 regions simultaneously. Using at least two regions for a single check is recommended in order to confirm failures across regions.
Currently, we support checks in the following regions:
- Seattle, Washington
- Dallas, Texas
- Piscataway, New Jersey
- London, UK
- Sydney, Australia
- Frankfurt, Germany
- Paris, France
- Amsterdam, Netherlands
- Singapore
- Moscow, Russia
Note: The first three selected regions of any check are always free. However, if more than three are selected, then those additional regions (beyond the first three) will be billed as additional native monitoring regions, which come at an additional cost. For specific pricing information, please visit the pricing page.
Frequency
The frequency of the check in milliseconds. The maximum frequency is every 30 seconds.
Note: Any frequency greater than every 60 seconds will force the component to become High-Frequency, at an additional cost. For specific pricing information, please visit the pricing page.
Timeout
The maximum number of milliseconds the check should wait on the host before failing.
In the case of DNS, the timeout is only used as the maximum wait time for SOA queries.
Regions Failed Threshold
The number of regions that must report a failed check before the entire check can be considered failed. Requiring at least two regions for this threshold is recommended in order to confirm failures across regions.
Consecutive Check Threshold
The number of consecutive check failures to require before posting a sub-operational state to the component. This field supports up to two "phases" of state escalation. For example, a component can be configured to go into "degraded" after so many consecutive failed checks, and then post "outage" so many failed checks after that. Otherwise, the component can be configured with a single-phase threshold that will simply post "outage" after enough consecutive failed checks.
Note that regardless of threshold settings, a component will post "operational" whenever a check succeeds, thus resetting the consecutive check failure count.
When either phase of this threshold is used, we recommend setting values greater than 0 to confirm a failure across consecutive checks through time, which protects against short, potentially meaningless or transient intermittencies (intermittent networks, server restarts, etc.).
ICMP (ping) Options
Percentage Failed Threshold
The percentage of addresses at the given target that must fail for a region to be counted as failed. This option only matters when there are multiple IP addresses behind the target when the target is a domain.
IP Version
The IP version to use when pinging.
HTTP(S) Options
Username
An optional HTTP Basic Authentication username.
Password
An optional HTTP Basic Authentication password.
Response Body Must Contain...
This field supports two different matching modes:
Exact match: If the requested page does not contain this exact (case-sensitive) string, then the check will fail.
Regex: If the requested page does not match against the given regex, then the check will fail. Click here for more information on the use and supported syntax of Hund regexes.
Response Code Must Be...
If the requested page does not return this response code, then the check will fail.
Headers
A list of additional HTTP headers to send to the target. The following list of header names are reserved and cannot be set by a check:
Accept-CharsetAccept-EncodingAuthenticationConnectionContent-LengthDateHostKeep-AliveOriginProxy-.*Sec-.*RefererTETrailerTransfer-EncodingUser-AgentVia
Follow Redirects
Follow any HTTP redirects given by the requested target. Please note that this check will only follow up to 9 redirects.
Verify Target TLS Certificate
Require the target's TLS certificate to be valid.
DNS Options
Record Type
The type of DNS record to query for on the target. Currently, we support the A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT record types.
Nameservers
An optional list of nameservers to make DNS queries with. This field is ignored by SOA queries since they use the nameservers yielded by querying NS on the target.
Responses Must Contain...
A list of assertions to make against the records yielded by the query. The format of these assertions is similar to DNS record syntax, but is slightly simplified and allows for only asserting parts of a record's RDATA, rather than the entire thing. The check will fail depending on the value of Response Containment.
This field is ignored by the SOA check, as it does not use assertions to determine the validity of SOA records. Instead, we ensure that every nameserver reported by querying NS on the target reports the same SOA serial. If your target's nameservers report conflicting SOA serials, we consider the check failed.
Example Assertions (for MX record type):
10 mail.example.com
spool.example.com
mail2.example.com
Note above how we can assert both the priority and domain (without the terminating period required by canonical DNS) of an MX record, or instead simply the domain.
Response Containment
Whether all of the assertions in the given list must match the DNS response, or rather just any of them (i.e. at least one).
TCP Options
Port
The port at the target to connect to.
IP Version
The IP version to use when calling the target.
Data to Send
Optional data to send to the target after connecting. If this field is left blank, nothing is sent to the target after connecting.
This field supports escape codes.
Response Must Contain...
This field supports two different matching modes:
Exact match: Text that the response from the target must contain exactly (case-sensitive). In exact match mode, this field supports escape codes.
Regex: A regex that the response from the target must match against. Click here for more information on the use and supported syntax of Hund regexes.
If you send data and expect the target to reply, you must populate this field. Leaving this field blank will prevent the check from receiving data from the target unless forced to wait for an initial response.
The "response" from the target that this text is asserted against will be the response from the target after sending data. If data is not sent to the target, this text is asserted against the initial response.
Wait for Initial Response
Whether or not to wait for an initial response from the target before sending data or closing the connection.
UDP Options
Port
The port at the target to connect to.
IP Version
The IP version to use when calling the target.
Data to Send
Data to send to the target. Unlike in TCP, this field is required.
This field supports escape codes.
Response Must Contain...
This field supports two different matching modes:
Exact match: Text that the response from the target must contain exactly (case-sensitive). In exact match mode, this field supports escape codes.
Regex: A regex that the response from the target must match against. Click here for more information on the use and supported syntax of Hund regexes.
Leaving this field blank will still cause the check to wait for a response from the target after sending data, though no assertions will be made about the payload of the response.
Metrics
Components of any kind can display the following metric(s). If you're using a different component type, just click the Add Metric Source button on the component's dashboard page.
ICMP (ping) Metrics
Response Time
This is the response time from your check's target to our servers.
Total Addresses
The total number of addresses pointed to by the given target.
Responding Addresses
The number of addresses from the total that responded to the ICMP ping.
HTTP(S) Metrics
Redirect Time
The amount of time it took from the start of the first connection through all redirects to just before the connection to the destination host is made.
DNS Lookup Time
The amount of time it took to resolve the DNS name of the destination host.
TCP Connection Time
The amount of time it took to establish a TCP connection with the destination host after resolving DNS.
TLS Handshake Time
The amount of time it took to perform the TLS handshake (if applicable) after the TCP connection was established.
Content Generation Time
The amount of time it took for the destination host to generate the content sent to the caller.
Content Transfer Time
The amount of time it took for the content to be transferred to the caller after it was generated.
Total Elapsed Time
The total amount of time it took for the HTTP request to finish, including all redirects.
Time to First Byte
The total amount of time, including all redirects, it took for the destination host to send the first byte of its generated content to the caller.
DNS Metrics
The DNS check does not currently report any metrics.
TCP Metrics
Response Time
The elapsed time between the first SYN packet of the TCP connection, and the subsequent SYN-ACK packet from the target. Since these packets have low application overhead, the elapsed time between them represents the current network latency akin to an ICMP ping response time.
TCP Connection Time
The amount of time it took to establish the TCP connection via the three-way handshake.
Initial Response Time
The amount of time it took to receive an initial response from the target after establishing the connection. If the check does not wait for an initial response, this metric is 0.
Initial Response Transfer Time
The amount of time it took to transfer the initial response after the first packet of the response. Normally, this metric will be close or equal to 0 unless the initial response spans more than one packet.
Request Transfer Time
The amount of time it took to transfer the request (i.e. the content of the Data to Send field) to the target.
Request Response Time
The amount of time it took for the target to respond to the request after finishing transferring the request to the target.
Request Response Transfer Time
The amount of time it took to transfer the request response after the first packet of the response is received. Normally, this metric will be close or equal to 0 unless the response spans more than one packet.
Disconnection Time
The amount of time it took to close the connection via either a four-way or three-way handshake, or a connection reset. If either side of the connection resets the connection, this metric will be close or equal to 0.
Total Elapsed Time
The total elapsed time of the entire TCP conversation from the first SYN packet to the last packet of the disconnection handshake.
UDP Metrics
Response Time
The amount of time it took to receive a response packet after having sent the contents of the Data to Send field to the target. Due to potential application overhead in generating the response, this response time is not a necessarily precise measurement of network latency, unlike in the ICMP and TCP checks.
Response Transfer Time
The amount of time it took to transfer the response from the target after receiving the first packet. Normally, this metric will be 0 unless the response spans more than one packet.
Total Elapsed Time
The total elapsed time of the entire UDP conversation from the first to the last packet. Normally, this metric will be equal to the response time metric unless the response spans more than one packet.