Notices in your dashboard
Incidents and planned maintenance are posted as notices at the top of your SendAxion dashboard. Critical and maintenance notices can’t be dismissed while they apply, so they stay in view.
SERVICE STATUS
Service status, told straight.
SendAxion doesn’t run an automated public status monitor, so this page won’t show you an “all systems operational” badge that nothing is checking. Here is where we post incidents and maintenance, how to tell whether a problem is on our side, and how to reach us.
WHERE WE POST NOTICES
How you’ll hear from us
Email about your workspace
When something affects your workspace directly, such as sending being paused, a renewal payment failing, a plan ending or a data request being completed, we email you about it.
Ask us directly
If you think something is wrong on our side, open a ticket or start a live chat. We’ll tell you what we know, including whether an incident is already being worked on.
INCIDENTS AND MAINTENANCE
What to expect
During an incident
Once we’ve confirmed a problem that affects customers, we post a notice in the dashboard, update it as we learn more, and mark it resolved when the service is back to normal.
Planned maintenance
We plan maintenance to avoid interrupting your sending. When work could affect the API, SMTP submission, webhooks or the dashboard, we post a notice in the dashboard beforehand with the time window in UTC and what to expect. If a request fails during that window, retry it: integrations that retry with backoff recover on their own.
IS IT SENDAXION?
Check where the problem is
Most delivery problems can be narrowed down in a few minutes with the information SendAxion already shows you.
API requests
Look at the HTTP status. 202 means we accepted the message. 400 points to the request itself, such as an unverified sending domain or a missing body; 401 to a missing or invalid API key; 403 to a plan that doesn’t include that kind of sending; and 429 to a reached sending allowance, with a Retry-After header that says when to try again.
502 or 503 means we couldn’t take the message at that moment. Retry with backoff, and tell us if it continues.
SMTP connections
Check the host (smtp.sendaxon.net), the port (587 with STARTTLS, or 465 with SSL/TLS) and the credential’s username and password. If you can’t connect at all, test from the same machine:
openssl s_client -starttls smtp -connect smtp.sendaxon.net:587If that fails too, your network may be blocking the port. Try port 465.
Delivery to recipients
Open the message in Message activity. If its timeline shows a reply from the recipient’s server, SendAxion handed the message over and the receiving system made the decision: 4xx replies are temporary and retried, 5xx replies are final. Messages to suppressed recipients are skipped on purpose.
Domains and your workspace
If messages are rejected for authentication, check that your SPF, DKIM and DMARC records are still published exactly as the dashboard shows, then run verification again.
If sending from your workspace has been paused, the dashboard shows the reason and lets you request a review, and we email you about it.
REPORT A PROBLEM
Tell us what you’re seeing
Check the basics
Look for a notice in your dashboard and work through the checks above.
Collect the details
Workspace, message IDs or recipients, times in UTC and the exact error text. See what to include.
Contact us
Open a ticket at our help desk, start a live chat from the Support button, or email support@sendaxion.com.
SOMETHING LOOKS WRONG?