Availability testing

The Availability Test feature needs to be enabled for each account. If you want to use this feature but don't see it in the Synthetic Classic Portal, please contact your account manager.

What is an Availability test?

Availability testing tells you whether your web application is up or down. The simple protocol-based tests provide a measure of up-time for your application.

Currently, the HTTP test type is implemented. Other test types may be added in future releases.

An HTTP test makes an HTTP call to the server to show whether the target URL responds with a valid return code. Besides testing web pages, you can test simple single-step REST and web services.

The test is not intended to load the entire page and execute client-side JavaScript. It simply confirms that the page responds and whether an error occurred. Availability tests use cURL to request web pages; you can specify a user-agent if your web application is sensitive to the browser type.

Availability tests are available to all Synthetic Classic users, with no special activation required.

HTTP test features

Availability tests can run from any Backbone nodes. The tests don't require scripting or recording; they're defined through the Tests page in the Synthetic Classic Portal, or through the [Availability Test API]. You can use the API to create or manage multiple tests at the same time.

An Availability test supports a single request. In the test settings, you can add custom headers for user-agent, cookies, etc. You can also configure optional pass/fail criteria such as validation text and response time threshold.

Availability tests consume fewer XF points than Performance (Backbone, Last Mile, Private Last Mile, Mobile) tests. They can be scheduled to run as frequently as once every minute.

2002 – Very early initialization code failed. This is likely to be an internal error or problem, or a resource problem where something fundamental couldn't get done at init time.

2003 – The URL wasn't properly formatted.

2004 – A requested feature, protocol, or option was not found.

2005 – Couldn't resolve proxy. The given proxy host could not be resolved.

2006 – Couldn't resolve host. The given remote host was not resolved.

2007 – Failed to connect() to host or proxy.

2008 – The server sent data that the engine couldn't parse.

2009 – We were denied access to the resource given in the URL. For FTP, this occurs while trying to change to the remote directory.

2010 – While waiting for the server to connect back when an active FTP session is used, an error code was sent over the control connection or similar.

2011 – After having sent the FTP password to the server, libcurl expects a proper reply. This error code indicates that an unexpected code was returned.

2012 – During an active FTP session while waiting for the server to connect, the timeout expired.

2013 – The engine failed to get a sensible result back from the server as a response to either a PASV or a EPSV command. The server is flawed.

2014 – FTP servers return a 227-line as a response to a PASV command. If libcurl fails to parse that line, this return code is passed back.

2015 – An internal failure to look up the host used for the new connection occurred.

2016 – A problem was detected in the HTTP2 framing layer. This is somewhat generic and can be one of several problems. See the error buffer for details.

2017 – Received an error when trying to set the transfer mode to binary or ASCII.

2018 – A file transfer was shorter or larger than expected. This happens when the server first reports an expected transfer size, and then delivers data that doesn't match the previously given size.

2019 – This was either a weird reply to a RETR command or a zero byte transfer complete.

2021 – When sending custom "QUOTE" commands to the remote server, one of the commands returned an error code that was 400 or higher (for FTP), or that otherwise indicated unsuccessful completion of the command.

2023 – An error occurred when writing received data to a local file, or an error was returned to the engine from a write callback.

2025 – Failure when starting the upload. For FTP, the server typically denied the STOR command. The error buffer usually contains the server's explanation for this.

2026 – There was a problem reading a local file or an error returned by the read callback.

2027 – A memory allocation request failed.

2028 – Operation timeout. The specified timeout period was reached according to the conditions.

2030 – The FTP PORT command returned error.

2031 – The FTP REST command returned error. This should never happen if the server is sane.

2033 – The server does not support or accept range requests.

2034 – This is an odd error that mainly occurs because of internal confusion.

2035 – A problem occurred somewhere in the SSL/TLS handshake. Check the error buffer and read the message there; it should pinpoint the problem slightly more. It could be certificates (file formats, paths, permissions), passwords, or other.

2036 – The download could not be resumed because the specified offset was out of the file boundary.

2037 – A file given with FILE:// couldn't be opened. Most likely this is because the file path doesn't identify an existing file. Check file permissions.

2038 – LDAP cannot bind. The LDAP bind operation failed.

2039 – LDAP search failed.

2041 – Function not found. A required zlib function was not found.

2042 – Aborted by callback. A callback returned "abort".

2043 – Internal error. A function was called with a bad parameter.

2045 – Interface error. A specified outgoing interface could not be used.

2047 – Too many redirects. When following redirects, the engine hit the maximum amount.

2048 – An option passed to the engine is not recognized/known. Contact Support for assistance.