Legacy Manual
Event - Send Email
A very popular event type is the "Send Email" event.
Before you can create an event to send an email, you must configure your SMTP server and return email address. Note that your SMTP server must be accessible on the network to be able to send emails, so it's possible a network failure may not be able to email you. PingPlotter will continue to try to send emails once a minute until it is able to get an email out.
Emails are a bit more complicated to set up than most Event types – as it is dependant on your SMTP server, and you don't want to be overwhelmed with emails when conditions are bad, but you *do* want to know what's going on.
First off, you can fire emails based on the standard PingPlotter notification types. See the associated documentation for more details.
Send e-mail to:
This can be an individual email address, or a list of addresses separated by either a , or a ; (both work equally well). Please do not set this up to be someone at your ISP unless they have agreed that they want to see this information. A huge portion of getting problems solved is playing the game right, and overwhelming people with automated emails is almost certainly going to work against you.
Email Subject:
This defaults to "PingPlotter Auto-Alert!", but can be customized with a variety of variables / text. Click here to see this list.
For emails, the $host makes a huge amount of sense (i.e.: $host is down!), while the time/date aren't as useful because the email already contains data about this in most cases.
Maximum email frequency and minutes to wait
The next two settings control the frequency at which you'll get e-mails during alert conditions.
We recommend settings both of these values to 0 (no delay) when using a "When alert conditions start" and "When alert conditions end" event types.
When using a "Every sample" event type, though, this will result in massive overload of emails, so you'll want to limit the number of emails sent.
The first (Maximum e-mail frequency) means that you'll only get emails that often for this alert/target/event combination. Once you get an alert email, you won't get *another* one until this amount of time has passed. If conditions call for an email to be sent, it's delayed until this amount of time has passed. Beware that conditions may have changed between the time the alert is "queued" (and delayed) and the point where the alert email is sent out (because it's been delayed by this setting). This can be confusing (which is why we recommend setting this to 0 on alert conditions start and alert conditions end events).
The second (How long to wait for worse conditions) specifies how long PingPlotter will wait after its first alert condition to send an e-mail. This option allows you to wait a few minutes to find out if it was a temporary or more permanent alert condition. You may not want one immediately - because you'll want to wait a bit more info to be included - so you may want to wait 5 minutes or so before that first e-mail gets sent off.
Testing and error messages
Once you have your e-mail set up, use the "test" button to see what the message will look like (and also to make sure all the settings are working). Any errors should be displayed here.
Many of the errors that occur during testing can be attributed to incorrect email setup – so go there and validate your settings.
Here are some specific knowledge base articles on possible error numbers:
Any Socket error is being generated by the SMTP server itself, not PingPlotter, so if you're getting an error number not listed here, or in our knowledge base, try doing a search on your favorite search engine to see if you can find more information about the error you're getting.