Server Error in '/w' Application

[SNad]

Hello,

One of our donate pages is throwing the following error (below) while using an embedded connect widget. Is this a click and pledge issue or a website/server error?

Thanks in advance!
Sonal

[ECunneenWE1]

Hi,

We are experiencing the same issue with two of our embedded donation forms. Is this a systemic Click & Pledge issue? Any help/advice would be welcome.

Thanks.
Elizabeth

[CnP.Support]

Good day!

A security update earlier today apparently had a problem with a server which was resolved.

We apologize for the inconvenience. Please test it and let us know if you still have issues.

[SNad]

Thank you for the quick response - it looks like it is up and running again!

In the future would it be possible to be alerted if an error like this happens again? The error was found by one of our staff members which caused confusion among our leadership team and we had a had to delay a mass email campaign because we couldn't identify the source. It would be nice to have an alert sent to admins so I could have an answer for them and alleviate some of the feelings of mistrust that occur which unexpected errors.

[CnP.Support]

We always do but in this case none of our external monitoring systems had reported it. We have a web farm and components run on many servers. We have internal testers (robots) and external testers (robots) that run constantly hitting each server from inside and the collective from outside. In a web farm you have N number of servers in the network and a load balancer that distributes the load based on the traffic to inside servers. For example a request you do now may hit server 1 and the next request goes to server 20. The collective sessions are shared and the rest is a bit more technical.

We learned of the issue with this post: http://forums.clickandpledge.com/for...-w-application

None of our internal servers had problem from inside and all passed our internal check prior to deployment. The external testers do not hit inside servers but hit the collective. When we test from outside we make randomized tests and it always follows that if a server has passed the inside test it should be OK. In this case one server had the problem with the update. The update was made at 5 a.m. and with low traffic the issue did not surface. Only when the traffic increased the issue surfaced and it affected the hits to that server.

When we saw the post to the forum we tested the page and could not see anything wrong and could not explain the issue. After testing each server with the reported session we found the problem and immediately fixed it by taking that server offline and resolving the problem and then brought it back online.

For a while we did not know if this is our issue or the client's but resolved it immediately once we determined the root cause. There was no time to report.. hope you see the issue.

[SNad]

Thank you for the thoughtful response - this is helpful context to have to explain to the leadership team and those involved. Thank you!