101–107 of 107 posts
Earlier quoted context omitted.
Thanks for the clarification! I'll pass that along to our products department. :-)
Who do you work for?
Earlier quoted context omitted.
Let me pose two theories for you. 1. The guy who got fired had an overzealous manager who fired with insufficient cause. 2. The guy who got fired had a history that we don't know, but the manager does, and this was the final straw. Both theories are possible. I personally have known a higher portion of guys fitting #2 than managers who would enable #1. Therefore conditional probability suggests to me that he was fire…
"(Even in #1 the firing was not her fault - it was the manager's.)" But in this case, it's not a simple binary case of was/was not "her fault". It's at least partly her fault, regardless of the accuracy of scenario #1 or #2. There is a chain of causality here, and it all starts with Adria's tweet/blog post. I'd also argue that your two theories represent a false dichotomy, and sussing out your conclusion based on the…
I'd also argue that your two theories represent a false dichotomy...
Actually they don't. Are we agreed that this event is insufficient cause for a firing? If so, then if this event was the real reason for the firing, then the manager fired for insufficient cause, which is my #1. If not, then there is more to the story, which is my #2. Those two possibilities are therefore logically complete.
However they are not mutually exclusive. There might have been more to the story, and yet the manager still fired for insufficient cause.
That said, what's going to happen now? The guy who got fired has just become a cause. If he's got any skills at all, he'll get another job. I'm confident of it.
Adria has become radioactive. She hasn't been fired, but if her employer keeps getting attacked because of outrage over this, that's a possibility. If she does get fired, she's going to be radioactive for a while. Her line of work requires her to be public about where she is. And no sane company wants to be included in the outrage aimed in her general direction.
Earlier quoted context omitted.
"(Even in #1 the firing was not her fault - it was the manager's.)" But in this case, it's not a simple binary case of was/was not "her fault". It's at least partly her fault, regardless of the accuracy of scenario #1 or #2. There is a chain of causality here, and it all starts with Adria's tweet/blog post. I'd also argue that your two theories represent a false dichotomy, and sussing out your conclusion based on the…
Fault is a legal concept. There is always a chain of events with many events that were necessary. But who had the power to make the decision? Who made it? That is who is at fault. In this case that wasn't Adria. (Not that her behaviour is anything to be proud about.) I'd also argue that your two theories represent a false dichotomy... Actually they don't. Are we agreed that this event is insufficient cause for a firi…
Earlier quoted context omitted.
If memory serves, if you can log into Mailgun, it will have some text on how to set up all those things on your dashboard. Congrats on switching - Mailgun has vastly superior deliverability, at least in my observation.
I'd love to hear why you think mailgun is more superior than sendgrid. I'm currently using sendgrid.
I have also noticed that false positives from other startups in my own spam folder are often sent through Sendgrid (though I suppose that's not dispositive since it could just be that more startups use Sendgrid).
Earlier quoted context omitted.
We've never been directly notified by them despite their SMTP breaking a number of times.
I'll just start following them on Twitter then. I've recently started working somewhere new where we use SendGrid, and this is the first outage I've been aware of.
* require you to use user:pass instead of keys
* no historical service status page
* poor notifications about downtime
* unclear explanation of uptime
Earlier quoted context omitted.
how does one send outage notices if the mail is down?
Have an offsite cloud server with a mail daemon that's ready to send a few thousand messages to customers when your main server is down.
Letting users set "I must ack notifications of outages or keep pinging me" would make sense, too.
I'd probably consider mobile push notifications with confirmation and/or voice or SMS as well.
Basically like Nagios, but for third-party components.