title | author | description | ms.date | ms.assetid | msc.legacyurl | msc.type |
---|---|---|---|---|---|---|
Troubleshooting HTTP 400 Errors in IIS |
rick-anderson |
This article describes the troubleshooting steps to identify the cause of various HTTP 400 errors when using IIS. |
11/27/2012 |
767eba96-0849-4f97-bd73-850362048d16 |
/learn/troubleshoot/diagnosing-http-errors/troubleshooting-http-400-errors-in-iis |
authoredcontent |
by Mike Laing
Tools Used in this Troubleshooter:
- Network Monitor
- HTTP Error logging
This material is provided for informational purposes only. Microsoft makes no warranties, express or implied.
Overview
After sending an HTTP request to an IIS server, an HTTP client (such as Internet Explorer) may display the following type of error message:
:::image type=»icon» source=»troubleshooting-http-400-errors-in-iis/_static/image1.png»:::
HTTP 400
The webpage cannot be found.
Most likely causes:
- There might be a typing error in the address.
- If you clicked on a link, it may be out of date.
What you can try:
- Retype the address.
- Go back to the previous page.
- Go to Bing and look for the information you want.
If the HTTP client is Internet Explorer, and the Show Friendly HTTP Error Messages option is turned off, the error may resemble the following:
Bad Request
In these scenarios, IIS has rejected the client’s HTTP request because the request did not meet the server’s HTTP parsing rules, or it exceeded time limits, or failed some other rule that IIS or HTTP.sys require incoming requests to adhere to. IIS sends the HTTP 400 — Bad Request status back to the client, and then terminates the TCP connection.
Troubleshooting Methods
When troubleshooting an HTTP 400 condition, it is important to remember that the underlying problem is that the client has sent a request to IIS that breaks one or more rules that HTTP.sys is enforcing. With that in mind, you will want to see exactly what the client is sending to IIS; to do this, capture a network trace of the client sending the bad request. You can analyze the trace to see the raw data that the client sends to IIS, and to see the raw response data that IIS sends back to the client. You can also use an HTTP sniffer tool called Fiddler; this is a great tool as it allows you to see the HTTP headers even if the client and server are communicating over SSL.
The next data item you will want to use is the C:WindowsSystem32LogFilesHTTPERRhttperr.log
file. Beginning in IIS 6.0, the HTTP.sys component handles incoming HTTP requests before they are passed along to IIS, and is the component responsible for blocking requests that don’t meet the IIS requirements. When HTTP.sys blocks the request, it will log information to its httperr.log file concerning the bad request and why it was blocked.
NOTE: For more information on the HTTP API error logging that HTTP.sys provides, see the following article:
- Error logging in HTTP API
https://support.microsoft.com/kb/820729
It is technically possible, although not very likely, that a client will receive an HTTP 400 response which does not have an associated log entry in the httperr.log. This could happen if an ISAPI filter or extension or an HTTP module in IIS sets the 400 status, in which case you could look at the IIS log for more information. It could also happen if an entity between the client and the server, such as a proxy server or other network device, intercepts a response from IIS and overrides it with its own 400 status and/or «Bad Request» error.
Sample Scenario
Following is an example of an HTTP 400 scenario, where a client sends a bad request to IIS and the server sends back an HTTP 400 — Bad Request message.
When the client sends its request, the browser error it gets back looks like this:
Bad Request (Header Field Too Long)
Capturing a network trace of the request and response, we see the following raw request/response:
REQUEST:
[!code-consoleMain]
RESPONSE:
[!code-consoleMain]
You’ll notice that the response headers don’t tell us as much as the error message in the browser. However if we look at the raw data in the response body, we’ll see more:
[!code-consoleMain]
You can see that the error message text displayed in the browser is also viewable in the raw response data in the network trace.
The next step is to look at the httperr.log file in the C:WindowsSystem32LogFilesHTTPERR
directory for the entry that corresponds to the bad request:
[!code-consoleMain]
In this scenario, the Reason field in the httperr.log file gives us the exact information we need to diagnose the problem. We see here that HTTP.sys logged FieldLength as the reason phrase for this request’s failure. Once we know the reason phrase, we can use the Error Logging in HTTP API article mentioned above to get its description:
[!code-consoleMain]
So at this point we know from the browser error message and the HTTP API error logging that the request contained data in one of its HTTP headers that exceeded the allowable length limits. For the purpose of this example, the HTTP: Uniform Resource Identifier header is purposefully long: /1234567890123456789012345678901234567890/time.asp.
The final stage of troubleshooting this example is to use the following article to see the HTTP.sys registry keys and default settings for IIS:
- Http.sys registry settings for IIS
https://support.microsoft.com/kb/820129
Since we know the reason phrase and error are suggesting a header field length exceeding limits, we can narrow our search in KB820129 as such. The prime candidate here is:
MaxFieldLength: Sets an upper limit for each header. See MaxRequestBytes. This limit translates to approximately 32k characters for a URL.
To reproduce this error for this example, the MaxFieldLength registry key was set with a value of 2. Since the requested URL had a HTTP: Uniform Resource Identifier header field with more than 2 characters, the request was blocked with the FieldLength reason phrase.
Another common HTTP 400 scenario is one where the user making the HTTP request is a member of a large number of Active Directory groups, and the web site is configured to user Kerberos authentication. When this occurs, an error message similar to the following will be displayed to the user:
Bad Request (Request Header Too Long)
In this scenario, the authentication token that is included as part of the client’s HTTP request is too big and exceeds size limits that http.sys is enforcing. This problem is discussed in detail, along with the solution, in the following Knowledge Base article:
- «HTTP 400 — Bad Request (Request Header too long)» error in Internet Information Services (IIS)
https://support.microsoft.com/kb/2020943
Other Resources
- Error logging in HTTP API
https://support.microsoft.com/kb/820729 - Http.sys registry settings for IIS
https://support.microsoft.com/kb/820129
- Remove From My Forums
-
Question
-
User1152153909 posted
Hi,
All I’m trying to do is create a simple website. To begin with. Nothing fancy, so all the fancy stuff I’ll leave toll later. I’ve gone through three different versions of «setting up a simple website. None of them have worked for me. I am looking for
an even simpler, step by step guide with examples on how to set up a simple, stupid website.And I thought Apache was supposed to be complicated! When I use the default site, I get the splash page no problem. When I try to serve my contect on a «new site» with the same IP and turn off the default website, I get the subject line error.
I’ve been working on getting this danged thing set up for almost a month now. I’d appreciate any help you can offer in a simple, step by step mode. I don’t need fancy, like I said. Nor a smart aleck. Just someone who’s willing to hold my hand through
the first setup.The frustration level here is intense.
Thanks!
Blaine
Answers
-
User-2064283741 posted
Ok. Then there seems to be something in your configuartion of the site you setup.
The easist way might be to place your applciation/site under the default website liek I sugegsted before.
So stop the current one. Place you code under where the folder/directory of the default site and try and browser directly to a page.
-
Marked as answer by
Tuesday, September 28, 2021 12:00 AM
-
Marked as answer by
When I try to hit my web app on port 8080 I get the following error
Bad Request — Invalid Hostname
HTTP Error 400. The request hostname is invalid.
I don’t even know where to begin to diagnose this problem
MrWhite
42.2k8 gold badges58 silver badges83 bronze badges
asked Jan 28, 2011 at 17:17
Did you check the binding is IIS? (inetmgr.exe) It may not be registered to accept all hostnames on 8080.
For example, if you set it up for mysite.com:8080 and hit it at localhost:8080, IIS will get the request but not have a hostname binding to match so it rejects.
Outside of that, you should check the IIS logs (C:inetpublogswmsvc#) on the server and see if you are seeing your request. Then you’ll know if its a problem on your client or on the server itself.
answered Jan 28, 2011 at 17:59
Taylor BirdTaylor Bird
7,7271 gold badge24 silver badges31 bronze badges
2
FWIW, if you’d like to just allow requests directed to any hostname/ip then you can set your binding like so:
<binding protocol="http" bindingInformation="*:80:*" />
I use this binding so that I can load a VM with IE6 and then debug my application.
EDIT: While using IIS Express to debug, the default location for this option’s config file is
C:Users{User}DocumentsIISExpressconfigapplicationhost.config
answered Sep 26, 2013 at 15:11
Jeff LaFayJeff LaFay
12.8k13 gold badges71 silver badges100 bronze badges
2
This page by Microsoft describes how to set up access to IIS Server Express from other computers on the local network.
In a nutshell:
1) from a command prompt with admin privileges:
netsh http add urlacl url=http://[your ip address]:8181/ user=everyone
2) In Windows Firewall with Advanced Security, create a new inbound rule for port 8181 to allow external connections
3) In applicationhost.config, in the node for your project, add:
<binding protocol="http" bindingInformation="*:8181:[your ip address]" />
Do NOT add (as was suggested in another answer):
<binding protocol="http" bindingInformation="*:8181:*" />
The above wildcard binding broke my access from http://192.168.1.6:8181/
itzmebibin
9,1338 gold badges48 silver badges62 bronze badges
answered Oct 29, 2014 at 22:44
ErwinErwin
5356 silver badges8 bronze badges
3
So, I solved this by going to my website in IIS Manager and changing the host name in site bindings from localhost to *. Started working immediately.
answered Aug 10, 2015 at 17:00
SINGULARITYSINGULARITY
1,10611 silver badges11 bronze badges
3
If working on local server or you haven’t got domain name, delete «Host Name:» field.
answered Apr 29, 2020 at 14:31
Don’t forget to bind to the IPv6 address as well! I was trying to add a site on 127.0.0.1 using localhost and got the bad request/invalid hostname error. When I pinged localhost it resolved to ::1 since IPv6 was enabled so I just had to add the additional binding to fix the issue.
answered Oct 30, 2015 at 21:45
Jeff CameraJeff Camera
5,3045 gold badges44 silver badges59 bronze badges
1
This solved my problem (sorry for my bad English):
-
open cmd as administrator and run command (Without the square brackets):
netsh http add urlacl url=http://[ip adress]:[port]/ user=everyone
-
in
documents/iisexpress/config/applicationhost.config
and in your root project folder in (hidden) folder:.vs/config/applicationhost.config
you need add row to «site» tag:
<binding protocol="http" bindingInformation="*:8080:192.xxx.xxx.xxx" />
-
open «internet information services (iis) manager»
(to find it: in search in taskbar write «Turn Window features on or off» and open result and then check the checkbox «internet information service» and install that):- in left screen click: computer-name —> Sites —> Default Web Site and
- then click in right screen «Binding»
- click Add button
- write what you need and press «OK».
-
open «Windows Firewall With Advanced Security»,
- in left screen press «Inbound Rules» and then
- press in right screen «New Rule…»
- check port and press Next,
- check TCP and your port and press Next,
- check «Allow the connection» and press Next,
- check all checkbox and press Next,
- write name and press Finish.
-
done.
answered Jul 12, 2017 at 22:05
izik fizik f
2,3492 gold badges16 silver badges17 bronze badges
I’m not sure if this was your problem but for anyone that’s trying to access his web application from his machine and having this problem:
Make sure you’re connecting to 127.0.0.1
(a.k.a localhost
) and not to your external IP address.
Your URL should be something like http://localhost:8181/
or http://127.0.0.1:8181
and not http://YourExternalIPaddress:8181/
.
Additional information:
The reason this works is because your firewall may block your own request. It can be a firewall on your OS and it can be (the usual) your router.
When you connect to your external IP address, you connect to you from the internet, as if you were a stranger (or a hacker).
However when you connect to your localhost, you connect locally as yourself and the block is obviously not needed (& avoided altogether).
answered Jan 26, 2013 at 9:26
MasterMasticMasterMastic
20.6k11 gold badges67 silver badges90 bronze badges
6
You can use Visual Studio 2005/2008/2010 CMD tool. Run it as admin, and write
aspnet_regiis -i
At last I can run my app successfully.
phant0m
16.5k5 gold badges49 silver badges81 bronze badges
answered Jul 28, 2012 at 4:13
I also had this issue, but it was related to AllowedHosts of my application configuration
If it’s a .Net application you should probably have appsettings.json
Have a look of it’s AllowedHosts and try to change it to all-allowed «*»
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"AllowedHosts": "*",
}
So in case of incorrect AllowedHosts value, you will also have BarRequest error
answered Jan 17, 2022 at 16:07
1
Check your local hosts file (C:WindowsSystem32driversetchosts for example). In my case I had previously used this to point a URL to a dev box and then forgotten about it. When I then reused the same URL I kept getting Bad Request (Invalid Hostname) because the traffic was going to the wrong server.
answered Jul 25, 2013 at 13:31
robakerrobaker
1,0287 silver badges11 bronze badges
I got this error when I tried to call a webservice using «localhost». I fixed it by using the actual IP instead (192.168…)
answered Jun 25, 2014 at 14:42
CosminCosmin
2,3472 gold badges23 silver badges29 bronze badges
1
I saw the same error after using msdeploy to copy the application to a new server. It turned out that the bindings were still using the IP address from the previous server. So, double check IP address in the IIS bindings. (Seems obvious after the fact, but did not immediately occur to me to check it).
answered Jun 3, 2015 at 20:49
dan9298dan9298
1951 silver badge11 bronze badges
Double check the exact URL you’re providing.
I saw this error when I missed off the route prefix defined in ASP.NET so it didn’t know where to route the request.
answered Sep 14, 2018 at 14:29
TaranTaran
12.4k3 gold badges43 silver badges47 bronze badges
Make sure IIS is listening to your port.
In my case this was the issue. So I had to change my port to something else like 8083 and it solved this issue.
answered Sep 23, 2019 at 11:26
DudiDudi
3,0491 gold badge26 silver badges23 bronze badges
Most of the time client-server communications occur ceaselessly and effortlessly. However, on occasion you may run into the HTTP 400 error, also known as a Bad Request error.
This error can indicate that a request has not been met successfully, or that the remote server that received the request was unable to interpret it, such as when the request has become corrupted.
Servers usually respond to requests in a specific and often fixed format, and so anything out of the ordinary can result in an error message. To add to the confusion, sometimes the server itself may cause the error, but this is rare.
In Firefox and Safari, these errors usually result in a blank page with no status code. But with Chrome, the browser will show a generic “This page isn’t working” message along with an error code.
Some other common HTTP 400 error messages include:
- Bad Request — Invalid URL
- Bad Request: Error 400
- HTTP Error 400 — Bad Request
- HTTP Error 400. The request hostname is invalid
- Bad Request. Your browser sent a request that this server could not understand
Website owners may also opt to customise their HTTP Error 400 page to ensure reliable hosting services. An example of this is when web servers run Microsoft Internet Information Services (IIS), which can break down the error in more detail, such as “400.3: Invalid If Header”, “400.2: Invalid Depth Header”, “400.1: Invalid Destination Header”, and more.
HTTP error 400 causes
There’s a mixture of problems that can lead to a 400 Bad Request error. Here, we’ll go over five typical issues.
1. Bad URL Syntax
A 400 Bad Request error is usually a client-side error. A good case in point is a URL string syntax error. Incorrectly typed URLs, or URLs that contain backslashes and other invalid characters can garble a request.
For example, the following URL will send you to a valid page.
https://www.itpro.com/network-internet
Access the same URL with an extra “%” in it, and your browser will throw a 400 Bad Request error.
https://www.itpro.com/%network-internet
2. Invalid Cookies
Cookies store information on websites you visit and may also record authentication data to speed up log in. If you can’t log into a website you previously visited, it means the cookie containing your log in data is no longer valid. This results in a 400 Bad Request error.
3. Incorrect file size
You may be trying to upload a file that’s too large to a website. The server will fail to fulfill your request and respond with a 400 error message in such a case.
Keep in mind, the hosting provider sets the maximum upload size limit at the server level. For example, the maximum file size limit for WordPress ranges from 4MB to 128MB.
4. Unsynchronized DNS Cache
Browsers read domain names as IP addresses, which are stored locally in the Domain Name System (DNS) cache to improve the browsing experience. A 400 Bad Request error can occur when the DNS data stored locally is out of sync with a website’s registered DNS information during a future interaction.
5. Server error
Servers can cause errors too. To check if there’s an issue with the server, try loading a website from a different browser and device. If the website fails to open in Edge, Chrome, Firefox, or IE, it’s likely a server-side problem.
How to fix a 400 Bad Request?
It’s hard not to be unfazed by an HTTP error that tells you little about the problem. That said, fixing a 400 Bad Request error takes just a few steps. We’ve put together a few useful tips below to help you find your way out.
1. Recheck the URL
Since a malformed URL is the most common cause of the 400 Bad Request error, make sure there are no typing or syntax errors in your URL. Alternatively, for long URLs, consider using an online URL encoder, which automatically detects non-ASCII characters or invalid characters in a URL, saving you time and effort.
2. Check your internet connection
If you keep seeing a 400 Bad Request on nearly every website you visit, check your internet connection or consult your internet service provider to rule out a poor connection.
3. Clear browser cookies
A website may fail to comply with your request due to old or corrupt cookies. As a quick fix, consider clearing your browser cache and cookies. Repeat this exercise from time to time to avoid running into a 400 Bad Request error.
4. Clear DNS Cache
This works similar to clearing browser cookies and cache, except that it’s locally stored in your computer and may contain outdated information that doesn’t sync with the current webpage. You can clear old DNS information and records from your system within the Command Prompt in Windows and Mac.
5. Compress the file
If you run into an HTTP Error 400 right after uploading a file, try uploading a smaller file. If that works, you may conclude that the initial file exceeded the server limit. The best workaround for uploading a large file is to compress it. Most websites permit zip files that fall under the maximum upload size.
6. Deactivate browser extensions
While this isn’t a common solution for a 400 Bad Request error, some browser extensions may interfere with cookies. Temporarily disabling them might resolve the problem.
7. Restart your system
If you’ve tried all the above fixes and the HTTP Error 400 still continues, you might want to try turning off the system and turning it back on again. Although often derided, rebooting a device is astonishingly capable of solving a range of problems. With the HTTP Error 400, you will want to not only restart your computer but any attached peripherals — including the router.
RELATED RESOURCE
IBM FlashSystem 5000 and 5200 for mid-market enterprises
Manage rapid data growth within limited IT budgets
FREE DOWNLOAD
However, if restarting your system does not solve the issue, there is likely a problem with the website server. The cause can be anything from an overheated server room to a data centre power cut. Unfortunately, this means there’s nothing further you can do, although there are likely teams of people working to solve the problem. Reporting the problem to the website’s administrators could bring you some solace, but they may also provide you with an estimate as to how widespread the issue is, or how it will take to resolve.
Websites such as Down Detector provide a way for the wider community to report problems, and so it’s a good idea to share the issue with others.
At the end of the day, HTTP Error 400 is very much like other HTTP errors in the way that its causes are frequently perplexing as well as baffling. In many cases, they can be traced back to a uncomplicated issue, such as expired browser files and cookies, wrongly inserted URLs, or even an incorrect file size.
A daily dose of IT news, reviews, features and insights, straight to your inbox!
There are a lot of IIS errors out there.
Way too many, right?
You as a sysadmin know that for sure – internal server errors, access denied errors,
bad request errors, and application host errors. All these IIS errors sometimes drive you crazy.
Here’s a list of the most common errors around IIS errors and the proven solution to them:
- “500 Internal Server Error” or “HTTP Error 500”
- “Error 500.19” or “500.19 Internal Server Error”
- “HTTP Error 503. The Service is unavailable.”
- “Error 403” or “403 Forbidden”
- “HTTP 404 – File not found”
- “Error 401: Access Denied” or “Error 401: Unauthorized”
- “400: Bad Request” or “Bad Request: Error 400”
- “APPHOSTSVC Error 9009” or “Warning 9009 – IIS-APPHOSTSVC”
- “HTTP Error 301 – Moved Permanently”
And you’ll find the solution to get rid of ALL IIS errors – forever: Test PRTG and get started within minutes!
1. IIS error:
«500 Internal Server Error» or «HTTP Error 500»
Quick fix
The 500 Internal Server Error is a common HTTP error code indicating that something has gone wrong on the web server. As each website can use an individual error code, the error message may also look similar to one the following messages:
- “500 Internal Server Error”
- “HTTP 500 Internal Server Error” or “HTTP 500 Internal Error” or “HTTP Error 500”
- “Temporary Error (500)” or “500 Error”
These error messages usually occur when the server is unable to specify the problem. The most common causes are incorrect permissions on your files or folders, a PHP timeout, or coding errors in .htaccess. To solve the problem, check the configuration of your site or look for further information in the error log via IIS manager.
Best Solution:
https://www.lifewire.com/500-internal-server-error-explained-2622938
2. IIS error
«Error 500.19» or «500.19 Internal Server Error»
3. IIS error
«HTTP Error 503. The service is unavailable.»
Quick fix
The IIS error 503 is a server error may occur when you try to connect to a web application. “Error 503 — The service is unavailable” usually occurs if the application pool associated with the web application you are trying to connect to fails to start. This may have been caused by an overload or ongoing maintenance.
To solve the problem quickly, follow these steps:
- View the system log in the Event Viewer to find the error. If the application pool fails to start, this error is logged in the system log.
- If you cannot find the relevant event in the system log, continue your search in the HTTPERR log file located in the following system folder: c:windowssystem32logfiles. Search for “503” to find out why the application pool failed to start.
Best Solution:
https://windowsreport.com/http-error-503-service-unavailable/
https://support.microsoft.com/en-us/help/2619402/error-503-service-unavailable-when-you-browse-windows-sbs-websites
4. IIS error:
«Error 403» or «403 Forbidden»
Quick fix
The error 403 Forbidden usually occurs when you are trying to access a directory or page that you do not have permission to access. You IIS web server may provide more specific details on the cause by adding a suffix number after the 403, for example “403.14 Forbidden” (Directory listing denied).
The solution depends on what caused the error to occur. If you cannot find details on the cause, try the most common quick fix solutions.
Best Solution:
https://www.lifewire.com/403-forbidden-error-explained-2617989
5. IIS error:
«HTTP 404 – File not found»
Quick fix
The 404 error message occurs when the web server is unable to retrieve the requested page. The most common causes of this IIS error are that the requested file has been renamed, deleted or moved to another location.
In order to solve the issue, make sure that the file you requested exists on the ISS. Also check if it is in the right location and has the correct name. To find out where the requested file is located, you can use the IIS MMC snap-in.
Best Solution:
https://support.microsoft.com/en-gb/help/248033/how-system-administrators-can-troubleshoot-an-http-404-file-not-found
6. IIS error:
«Error 401: Access Denied» or «Error 401: Unauthorized»
Quick fix
If you receive error 401 by your IIS, you are facing authentication problems. The error occurs when the authentication to the admin or helpdesk portal fails due to a misconfiguration of authentication settings.
To fix the problem, make sure that your account has the required permissions by verifying the authentication settings in IIS Manager.
Best Solution:
https://kb.netwrix.com/1162
7. IIS error:
«400: Bad Request» or «Bad Request: Error 400»
Quick fix
IIS error 400 occurs when the server was unable to process the request sent to the website server. The most common cause of the Bad Request error 400 is an invalid URL, but it may occur due to a different cause as well.
To solve IIS error 400, make sure that the URL you have entered is correct. Typing errors or non-allowed characters in the URL are the most common cause of the Bad Request error. If the error still occurs after verifying the URL, clear your browser’s cache, DNS cache and cookies and try again.
Best Solution:
https://www.lifewire.com/how-to-fix-a-400-bad-request-error-2617988
8. IIS error:
«APPHOSTSVC Error 9009″or «Warning 9009 – IIS-APPHOSTSVC»
Quick fix
Warning 9009 is an IIS error of the Application Host. It occurs when the Application Host failed to delete the history directory. The Application Host Helper Service detects any changes in the ApplicationHost.config file and creates a backup in a subdirectory. However, the maximum number of subdirectories is 10. If this number is exceeded, the oldest one is usually deleted. If this process fails, error 9009 occurs.
To solve this problem, stop and restart the Application Host Helper Service (AppHostSyc). The AppHostSyc will then start the service and delete the subdirectory automatically. If it still fails to delete the history directory, try restarting the service manually.
Best Solution:
http://intelligentsystemsmonitoring.com/knowledgebase/internet-information-services/event-id-iis-application-host-history-configuration-185366/
9. IIS error:
«HTTP Error 301 – Moved Permanently»
Quick fix
ISS error 301 is a status code that informs the client that the location of a requested resource has permanently changed. If this server-side status comes up unexpectedly, you may want to diagnose the problem.
The first step to solve the problem is to check if there are any incorrect redirect instructions on the server configuration files or your web server software. You can also check the application logs to look for further information of the possible cause.
Best Solution:
https://airbrake.io/blog/http-errors/301-moved-permanently
Choose your solution: Bugfix or replacement
With PRTG you’ll never have to deal with
IIS errors again. Ever.
Trusted by 500,000 users and recognized
by industry analysts as a leader
“Fantastic network and infrastructure monitoring solution that is easy to deploy and easier still to use. Simply the best available.”
Read more reviews
“Software is absolutely perfect, Support is superior. Meets all needs and requirements, this is a must have solution if you are needing any form of monitoring.”
Read more reviews
“The tool excels at its primary focus of being a unified infrastructure management and network monitoring service.”
Read more reviews