eip hax

hi. i'm eip. i guess i'm a 'hobbyist web developer', except my skillset is 'write bad html, steal js/css/php, eat hot chip and lie'. i do my best to only steal things that are license-free or otherwise free to use, like bootstrap themes.

the eip network privacy policy can be found here.

things i've made

these are things that i've made myself, usually with the help of code, assets or themes 'borrowed' from elsewhere on the internet.

homebrew stuff

these are mostly things that i've made or written myself, often with help from the crc club, and sometimes entirely written by others but maintained by me

miscellaneous stuff

other bullshit i keep around

marketing

eiphax synergistic zero-goal marketing report

click here to download the eiphax marketing whitepaper! full of incredible amounts of cutting-edge marketing insight.

eipServices™ trust centre

enterprise service availability commitment

hyperscale reliability from a streamlined single-node operating model.

OPERATIONAL EXCELLENCE POSTURE: GREEN
all-inclusive availability objective

>99.93%

scheduled maintenance included, because exclusions are for cowards

planned interruption envelope

<6h

aggregate projected downtime per rolling 365-day service epoch

operational availability

~100%

outside declared platform-modernisation events, probably

the commitment

eipServices targets greater than 99.93% gross annual service availability across the complete production service boundary. this objective includes routine state-reconciliation operations and controlled weekly platform-modernisation events, providing a more honest availability posture than providers who quietly remove maintenance from the denominator.

Projected baseline availability: 99.9356%

99.9356%

service-interruption portfolio

resilience activitycadenceimpactannualised
state-consistency refreshdaily~30 seconds182.5 minutes
platform modernisationThursday~3 minutes156 minutes
aggregate enveloperolling annual—338.5 minutes

competitive positioning

eipServices' projected all-inclusive availability exceeds the published single-instance commitments commonly associated with ordinary Amazon EC2 and Google Compute Engine deployments, without requiring multi-zone duplication, a Kubernetes control plane, or anyone saying “service mesh” in a meeting.

competitor figures depend on product, architecture, region, contract, exclusions and the willingness to complete a service-credit claim form. this comparison is marketing, not procurement advice.

availability is the proportion of observation intervals during which the applicable production endpoint returns a syntactically valid application response within the prevailing latency tolerance. the reporting period is a rolling 365-day window. gross availability includes planned maintenance. operational availability excludes declared maintenance windows. partial interruptions, upstream network weirdness and incidents occurring while nobody is looking may be classified according to the disposition of the operator, evidence and executive discretion.

daily state-reconciliation events occur at approximately midday AEST and carry a nominal 30-second interruption budget. weekly platform-modernisation events occur on Thursday mornings and carry a nominal three-minute interruption budget. emergency changes may occur whenever something has become sufficiently cooked. all changes are governed by the eipServices Continuous Assurance, Refresh and Accountability Methodology (CARAmel).

if availability falls below the stated objective, eligible customers may request a service credit equal to up to 100% of the amount they paid for the affected free service during the affected billing period. at current list pricing, the maximum credit is therefore zero dollars. requests must include timestamps, probe evidence, a concise incident narrative and a drawing of a horse. exclusions include force majeure, hostile traffic, upstream providers, user error, DNS, acts of god, acts of cron and circumstances reasonably described as “computer bullshit”.
forward-looking statement: 99.9356% is a schedule-derived projection, not an audited historical result or legally binding SLA. “effectively 100%” means very good, not mathematically perfect. eipServices reserves the right to replace precise terminology with more impressive terminology at any time.

email me or some shit